Doing Features and User Stories the Right Way

Essentially, a feature is a user story or a group of stories (epic) that are related and deliver a package of functionality that end users would generally expect to get all at once.

What a feature should look like and how it should be applied?

The first and foremost is that it should provide business value. That means it should determine the health and well-being of the web app in the long run. Business value expands the concept of value beyond economic value (also known as economic profit etc.) to include other forms of value such as customer value. As you know, these values are not necessarily measured in monetary terms.

Secondly, a feature should be possible to estimate which means it must have enough definition for the developers to provide an estimate of the work involved in implementing it.

If the feature is too time-consuming, it should be broken down into smaller user stories - preferably it should be small enough to fit within one iteration.

Key advantages to breaking down features into smaller user stories

• Firstly, it makes estimation easier and more accurate – things that take a long time tend to be very difficult to estimate.
• Secondly, it allows us to track progress on the feature accurately. Breaking down stories is pretty hard though because you have to make sure that they still deliver value. Usually those more complex features will be described in epics.

Within the project, Netguru team members work QAs that take care of the quality of the code and we apply the concept of test-driven development. Therefore a feature should also be testable and understandable for all team members.

We always urge others to remember that user stories are not a contract - they are usually hints or reminders of features for the team and clients to negotiate and collaborate to clarify the details when the time of development nears.

How to write a good user story?

A user story (or several user stories in an epic) that describes a desired feature (functional requirement) should be written in a narrative, plain, understandable form for all team members. User stories are usually created by clients or myself. The format is usually not standardized. We try to avoid technical stories though.

Usually a user story has the following:

1. Title - for example, As a [user], I want [function], so that [value].

   As an admin I want to have an access to admin panel, so that I have information on basic settings (users, passwords, editing and deleting profiles)

   As an logged in user, I want to be able to edit my profile, so that it is updated

   As a user I would like to be able to search through website so that I can find content I need easier and faster;

2. Points - A relative scoring system, usually estimated by a developer as a measure of complexity, and indirectly the effort to complete a feature story. In most cases we use a 1 point to value 0.5 engineering day (2 points - 1 full engineering day, 4 points - 2 full engineering days etc.);

3. Requester (the client or project manager) and an owner (developer assigned to the task);

4. Descriptive copy (acceptance criteria, conditions of satisfaction) that define the details of the work to be done and determine when a story is completed, ready for tests and working as expected. A good way of gathering details is to ask additional questions such as ‘What if … ?’, ‘Where …?’, ‘When …?’, ‘How …?’. We also use examples and graphs to visualise our way of thinking.

5. References to external documents (such as screen shots, mockups etc.);

6. Comments done by any of the team members.

Conceiving good features and writing user stories out of them is not an easy task, especially for new projects and members who are used to different approaches and methodologies.

Mistakes happen, therefore communication between the team and the client is an essential part of our work to avoid (in the worst case) implementation of a wrong deliverable. The best idea is to follow agile methodologies’ best practices and discuss thoroughly every feature before we start to work on it, and then again during the development.

Therefore fundamental part of our daily schedule is to attend daily standups, planning meetings, work review meetings and retrospective meetings. Other forms both of oral and written communication help a lot!