There’s already several articles on splitting of User Stories out there, but I have a slightly different approach – and a new acronym that I like to share so bare with me.
My advice is to INVEST in good functional splitting and when functional splitting is not enough you use SOUND advice for additional ideas on how to split. And spice it all up with some common sense as usual of course;-)
This article is based on User Stories, but the same advice applies if you are using Use Cases in an agile setting. Then you normally first split into different flows in the Use Case, but when that is not enough for a good size the ideas here can help you split further.
You may think that it is overkill with all this debate on how to split User Stories. But personally I think it is a key skill in any agile team in learning how to produce value in a steady, fairly predictable and good way. And many teams are really struggling with this in my experience.
Common advice when working with User Stories and iterations (or sprints) is that you should be able to fit a number of stories into a sprint.
In general I think it makes sense to have a size of stories so you can do 3-10 stories in a sprint (per team). The team should always be able to complete and test a User Story within a sprint – with the exception of Spikes, see below.
Too many stories probably means that you are dealing with too much detail and can lose the overview and the real valuable things for the users.
Too few and you might not be dealing with prioritization on the right level and it might make planning and resource utilization more difficult.
Agile teams frequently have some issues in getting good at splitting User Stories so I will share some guidelines on how to get started.
First of all, the natural way to split User Stories is in functions with a value for some user. This should always be the main option, other alternatives should in general only be considered when this is not enough.
Use the INVEST acronym as coined by Bill Wake as excellent support on finding a good functional split.
- I – Independent
- N – Negotiable
- V – Valuable
- E – Estimable
- S – Small
- T – Testable
I am not going into the details around this, Bill’s article is a good start on this way of thinking. One comment only since many teams are struggling with this part is that Indepent should really be seen as a guideline that sometimes will not be feasible (if you are to meet the other parts of advice on size and splitting). Sometimes the best split will mean that there will be some dependency between stories. An example would be a search function which has been split over different kind of search parameters. That split will normally be dependent when it comes to the size (make a note of that in the Product Backlog). But you should always aim for having stories that bring value independent of each other.
So what to do when you are not able to break down a story in functions that follows Bill’s advice? Here is my suggestion to get started finding ways:
- S – Spike
- O – Options
- U – Unusual flows
- N – Nonfuntional requirements
- D – Data
A spike can be used when a User Story is too uncertain or not enough understood in some way. The spike is used to clarify it enough so that it can be planned – usually for a later sprint.
Spikes should in general only be used when uncertainty is high and should be seen as an exception. Many teams are investing unnecessary time by preparing too much for all User Stories and not keeping the User Stories Negotiable and Small.
The most common spikes are used to drive out risk and uncertainty around:
- Technical solution
- User experience
A spike might be done through research, prototype, implementing some code or any other way that makes sense to drive down the uncertainty to an acceptable level.
Many teams spend time unnecessarily on doing Spikes for all requirements (but they are probably not calling it Spikes). Especially when working with Use Cases and when having specialized Analysts on the team. The problem with this is not only that you capture much information before you need it (sometimes never). It will often also inhibit the Negotiations. If a lot of details are in a requirement people are much more reluctant to be creative and come up with different ideas for obvious reasons.
Only use Spikes when there is a need for them!
Options are closely related to the negotiation part of INVEST. Sometimes a negotitation means selecting a certain way of doing a User Story and that’s it. But sometimes it can really help thinking about optional ways of doing the story and use that as a way of splitting the story. “Nice to have” things can often be postponed to later (and then there might be a stream of higher prioritised stories meaning that “good enough” really becomes “good enough”!).
For example: You have a User Story that contains some field with manual input of data through a user interface. The team and the Product Owner is discussing data validation of the input. There might be many options on how advanced to make this – or not to include it at all. But it is still the same function delivered to the user.
Another example might be doing something with a nice drag and drop interface or with a simpler solution.
Sometimes there are flows through the application that are rare, and it can make sense to do a first version of the functionality that ignore the special cases or deal with them in very basic way and later add the final handling of special conditions. For example, you have an application that let’s you configure a product and then order it. When you choose a configuration that is not available the Product Owner might want to notify the client of this and advice on a different configuration. In a first version it might make sense to only notify the client that current configuration is not available.
When you have challenging demands on non-functional requirements, for example on performance or security it can often make sense to make a first version that provides the functionality and a later story that makes it pass the non-functional requirement verification.
Three different ways of thinking about splitting User Stories along datalines:
Input – Finding ways to limit the input data. For example the example above with different search parameters.
Output – In a similar way to input data, you can find ways of slicing output data. For example you might have different sets of data that should be presented for different users and can start with a subset of this data.
Device – You might have several input and output devices which makes a natural way of splitting. For example you might have an application that can receive input data for a function through a user interface or from another application which might make for a good split. Sometimes it can also make sense to provide limited functionality without a user interface (in a B2B application) and make it possible to use through manual setting by support personell.
Sometimes it helps finding ways of splitting along data lines by thinking about different user roles.
This might provide you with some guidelines on how to split User Stories. If you combine this with common sense and find your own ways I am sure you will be a master splitter in no time!
If you want to dig deeper into the subject try Richard Lawrence post on Splitting User Stories for a slightly different take and more examples.
[…] What can you try if the team is still struggling to break down the stories using the advice above? Another acronym to remember: SOUND. […]