Splitting user stories

I should start this post with an admission – I do not claim credit for any original thought here. What follows is taken from my own notes and has been accumulated over a number of years. I most recently tweaked my own notes and the way I explain this stuff after hearing Jeff Patton’s talk from the UK Lean Kanban conference on infoQ.

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