Agile requirements – back to basics

Much has been written about User Stories however, it is still a subject that I find people struggling with.

In this post I intend to review what are the choices that we make that enable us to claim a requirements approach as agile and how can user stories (when applied well) help us achieve this agility.

An agile approach to requirements should

• Defer investments
• Support just in time elaboration
• Encourage collaboration
• Support planning

The most common approach to agile requirements is User Stories. A user story represents a need on behalf of a specific stake-holder.

What is a user story?
User stories represent a need in terms of the individual who would benefit and the goal they are trying to achieve. For example an on-line book seller might have the story: As a customer I would like to search for a book by ISBN so that I can make a purchasing decision.

User stories can also be written on behalf of stake-holders who may never interact directly with the system, for example: As a support representative I would like the system to log activities and errors so that I can establish cause of a failure. In this way stories can be written to represent other aspects such as audit, testability, extensibility and performance requirements.

By representing stories in this way we can provoke valuable discussions regarding true need of a feature and it’s relative priority in the backlog. It is not uncommon to find teams working on what seems like a sound requirement that, when represented in this way, is shown to have little or no value.

So how do user stories meet the desires stated above?

Defer investments
A user story can be expressed at a very high level early in a development project. As the story moves over time towards the top of the backlog it can be split. This approach results in small items at the top of the backlog and large items at the bottom. The items at the top have been split and appropriate details added such that they are both small enough to deliver in an iteration and detailed enough that work can begin. Low priority items may never justify this degree of investment.

Support just in time elaboration
A story is often said to be a trigger or promise to have a conversation. With an on site customer a card with a few notes may be sufficient to trigger that. With non-instantly available customers we may choose to gradually build up the detail and supporting information (e.g. acceptance tests / criteria) prior to development commencing. The key here is to avoid the temptation to elaborate all of the user stories up front.

Encourage Collaboration
As user stories are elaborated we will need to engage with business stakeholders, user interface/experience designers, testers and developers (maybe others too) in order to establish the true requirement. As conversations of this type continue throughout the project we achieve a shared appreciation across what could other wise become distinct areas of the project.

Also, the way we handle these things can further enhance collaboration for example WIP limits and short iterations both place a tension on teams to find ways to collaborate.

Support Planning
Planning is usually necessary to answer questions like; when will it be done? and how will I know it’s on schedule?

User stories are often estimated using planning poker. This provides a low cost way to compare relative sizes. We can do this at low fidelity with very little information to support long term plans. For shorter term targets we can break stories down and add detail to gain a higher fidelity estimate. When planning an iteration we may be able to break down stories to such a degree that they can be scheduled and delivered in a couple of days. Where this is not possible a task break-down may be used to gain an appropriate fidelity for setting expectations for the next 1-4 weeks.

So where can I find out more?

See what Ron Jeffries has to say on the subject of the 3 critical aspects of user stories

• Card
• Conversation
• Confirmation

Also, Mike Cohn has plenty to say on the subject. Not to mention his book User Stories Applied which is available on google books!

What next?

In this short post I’ve mentioned splitting user stories more than a few times. In the next one I’ll provide a number of techniques that will support you in ensuring that your User Stories are the right size for today.

Technorati Tags: User Stories, Agile Requirements