Last week I had the pleasure of running a user story workshop for a group of very experienced folk with a broad range of backgrounds and skill sets. We convened the workshop to discuss the challenges that present themselves when we apply user stories for the first time on a real project.

The conversation was broad ranging but, since a number of people have told me that attending the workshop was valuable, I’ll try to capture some of the key issues.

What is a user story?
User stories have been described many times and in many ways, including the following:

• A requirements elicitation technique
• A prioritisation technique
• A planing technique
• A means to capture a requirement
• A means to defer capturing the requirement
• A unit of scope
• A question waiting to be asked

To some degree each of these are true. My personal favourite definition is “a promise to have a conversation”. This cuts to the heart of the approach. We use user stories to capture the need to dig deeper later. Early in a project we find out lots of desires about the end product. Many will grow into deployed features but many will never be built. Some may be valuable but turn out to be too expensive. Others may turn out to represent little value so be lost.
By having a very low fidelity mechanism for capturing requests we can see the shape of a product and the range of needs without delving into detail.

What is a story’s life cycle?
In the workshop I used Ron Jeffries model of a the life of a user story:

• Card
• Conversation
• Confirmation

Over a story’s life it will move from being an idea to being captured on a card i.e. deferred. At some point we will want to know more so we go talk to the appropriate people. We may capture this conversation in any number of forms including notes, diagrams, wireframes and examples. The final stage is to confirm that the story is satisfied. We typically capture acceptance criteria for a story before commencing development, this may or may not be automated as a set of tests. Following development we will demonstrate that the user story is satisfied.

What remains of a story post development?
We should be able to remove all trace of the story post development. Any long life artefacts will be created as a result of the story i.e. these are part of the acceptance of the story.
Stories are a poor solution to documenting a system because of their fragmented nature. One approach I have used in the past is to provide informal, live, versions of documents during development. These can be polished (if necessary) at the end of development. This approach emphasises documenting the right thing at the right time.

Who is a user story about?
User stories are written on behalf of users but also stakeholders. This means that we can express what are often referred to as “non-functional requirements” as stories for a stakeholder e.g. As the Security stakeholder I would like to use 256 bit SSL so that the site is conformant with our security policy.
We also write stories for personas, this allows us to place appropriate emphasis on the class of user who we are building the feature for and ensure that the specific user types goal is the focus rather than something more generic.

We delved into other areas I’ve written about previously too such as MMFs. I hope that this triggers some useful thinking but for me it’s always worth remembering why we use User Stories – to defer analysis until the right time while retaining a view of what the future might look like.

Craig has a valid concern that we might loose sight of our Sprint commitment if we have high and low priorities within the sprint, what if we don’t get to low priority stuff, well it was only low priority! He also raises concern over the degree to which the team is empowered if the Product Owner specifies a priority order for within the sprint.

By contrast Karl has his focus firmly on WiP (work in process), and through that lens the sprint is secondary to a focus on flow, prioritisation will encourage the team to focus on flow. I have some sympathy with this point of view.

As is so often the case I feel that I fall between these two camps.

• I believe in an empowered team who pull from the backlog
• I believe in the team making a commitment to a sprint scope
• I believe in the team self-organising around moving that scope through to releasable product

But, there is always a but, these things don’t preclude prioritisation.

We pull from the backlog in order to take into account team capacity / capability. We pull in the correct amount of work with an appropriate profile e.g. not all database heavy wok if we have limited DBA capability. This means that the team may not always pull items from the very top of the backlog. The team commitment is an open honest expectation that this work can and will be achieved by the end of the sprint. We don’t sack or punish the team if a commitment is missed, in fact it could be argued that the commitment should be missed from time to time due to special causes. We don’t want to pad sprint plans with high amounts of contingency. Finally the team self-organise around achieving the goal.

When I introduce teams to Scrum I recommend working against a prioritised sprint backlog. Why? The prioritisation helps in a number of ways:

• The team is challenged to find ways to move stories to Done faster
• The team is encouraged to collaborate and help each other out in favour of picking new tasks
• We bind people to tasks late, prioritisation helps them select tasks according to team need rather than specialisation
• Where a sprint commitment is missed we loose 1 story rather than a bit from each story.

So in short, I agree with much of what Craig has said, it should not be the responsibility of the PO to prioritise the sprint backlog. However, I do see the need for the team and PO to collaborate in order to ensure that the needs of the business do not take second place to the needs of the process. I also share much of Karl’s motivation with respect to limiting WiP and achieving Flow.

For me prioritisation is a strategy that a team can use to self organise around a given sprint commitment. It encourages collaboration and mitigates risk, how can that be bad?

The way I think of splitting user stories is through identifying axis. Some examples of axis are:

• Steps in a workflow
• Usability
• Quantity of data
• Asymmetric value
• Stakeholder needs

Steps in a workflow
The first of these is fairly self evident. On a recent project we had the need to implement a user story to purchase an item. This fell into an initial workflow design and mock-up stage followed by 4 user stories relating to the four stages of the workflow, checkout, select shipping method, submit order, order confirmation. This approach enabled us to deliver working features based on mock-ups followed by iterative improvement.

Usability

Another approach to the same problem could have been to split along a usability axis. This would involve and early “ugly” version followed by iterative usability improvements. This approach can be more effective if the screen design is novel and uncertain or the technical risk around order submission is being brought forward as a mitigation. A further usability axis would be to separate core functionality from enhancements such as auto-completion and other AJAX magic. A further example that comes to mind is a search capability, initially searching was by full words only on one field, gradually the back end was enhanced to do partial words and check multiple fields. At the same time the search results view was being enhanced to enrich the user experience.

It is in this category that we see Patton’s considerations of Bare Necessity, Capability & Flexibility, usability, performance, sex appeal manifest. His final axis is Safety which more clearly maps to stakeholder needs below.

Quantity of data

Quantity of data can be an issue where it significantly impacts the size of a task. For example where the datasource differs. It may be possible to establish a workflow while limiting the variety of variation of inputs or scenarios. An example might we limiting a registration form to accepting only a minimal customer details or limiting a report to showing a subset of the data. The later approach may allow some proof of function and review of layout earlier than if all data sources / types / fields were considered.

Asymmetric value

Value is a core consideration with user stories. It may be worthwhile considering how the value of the user story is gained. I worked on a system some time ago which was incrementally adding features in order to retire an older system. Our key goal was to minimise the users interaction with the old system. The user story under consideration was “create and trade financial instruments”. It turned out that while at first glance these were an atomic unit the users would trade instruments many more times that they would create them. Thus, we could reduce the users interactions significantly by providing the trade facility requiring the users to, in the short term, create instruments through the older system.

Stakeholder needs

Despite the name “User Stories” and stakeholders needs can be represented as a used story. During development it can be useful to view a user story from the perspective of security, operations, finance (and others) where one of these places a significant burden on a user story it may be appropriate to separate the two goals. An example of this can be as simple as data validation e.g. post codes or Captcha fields which do not benefit the user but some other stakeholder.

If all else fails

We could always fall back on using architectural lines to split a user story of breaking out a component that needs to be built. This approach is often at the top of the list when developers begin to consider splitting stories. I prefer to leave this as a last resort, we shouldn’t deny that it is an option but as my experience in splitting these things has increased it is a resort that I find myself reaching for less and less.

Technorati Tags: Agile Requirements, User Stories

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