5 tips for getting User stories to the right size

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

Leave a Reply

Your email address will not be published. Required fields are marked *