One issue I often see in Agile is user stories that aren’t sized appropriately. This can cause issues in completing within a sprint and can create large fluctuations in velocity. It often results in items that are poorly defined and estimated. All of this causes problems for delivery quality.
Remember, user stories should always take the format:
As a <user type>,
I want to <Action>,
So that <Reason>
Here are 5 tips for getting user stories to the right size:
1) Spend the time maintaining the backlog
First and foremost, those stories won’t write themselves. The team, including the product owner, needs to spend time ensuring that there is a good backlog of stories for upcoming sprints. Mike Cohn suggests that about 5-10 percent of the teams time should be spent on backlog grooming. There is often a temptation to see this as wasted time, especially for developers; don’t cut it out – in my experience it is time well spent and reduces the time needed for sprint planning and general queries during the sprint.
2) Look at how many acceptance criteria you have
There isn’t a hard and fast rule for how many acceptance criteria a story should have, but it is a good indication of a story that needs breaking up if you have a large number of acceptance critiera. During the grooming, use this as a quick indicator of whether a story should be split further.
3) Avoid AND in your stories
using AND in your story description, especially in the action, is a good sign the story should be split. For example:
As a new user I want to be able to sign up and login so that I can customise my settings
should be split into two (or probably even more) stories:
As a new user I want to be able to sign up so that I can customise my setting
As a new user I want to be able to login so that the site remembers my previous setting
If you see the word AND in a story always try to break it into separate stories
4) INVEST in your stories
Use the INVEST acronym to help guide whether your story is fit for purpose:
Independant: ideally the story should have no dependancies on other stories, although in practice this can be difficult
Negotiable: the story should be a guide for the team, not a strict definition
Valuable: it should provide standalone usefulness for the user
Estimatable: the team should be able to assign story points to it…..
Small: ….. and those story points should be small enough that the item easily fits within a sprint
Testable: It should be clear how the story can be verified
5) Use story splitting techniques
There are a number of techniques to help you decompose stories. My personal favourite is this approach by Richard Lawrence which provides a three step process:
Prepare the Story
Follow Splitting patterns
Evaluate the split
Have a look at his post, it provides a nice diagram with explanations of his splitting patterns