Right-sizing User Stories

I was asked by a customer to give a talk about right-sizing user stories. Below is the summary I gave them. This is by no means an original bit of thinking but ideas pulled from a number of sources (1, 2), however it made a nice little summary so I thought I’d post it.

Form

A User Story typically takes the form of:

As <type of user>
I want <some goal>
So that <some reason>

So what is the right size ?

There is no right answer !

It pretty much depends on the team. In particular their skill levels, the process they follow and their domain knowledge. All these factors impact the size of a User Story that is right for the team.

A well oiled team, working in a domain they know inside and out can consume and deliver much larger User Stories with ease. A newbie team with little domain knowledge is going to require much finer sized (and easier to consume) User Stories.

Rules of thumb

However, there some rules of thumb that can help you find the right size of User Story for your team:

  • small enough to be understood by the team and be implemented by the team in a short space of time
  • big enough to represent business value in its own right
  • big enough to deliver on its own

A User Story is NOT…

  • A task (e.g. a small bit of work that has no standalone business value)
  • A requirement

Instead a User Story:

  • Groups a set of tasks to be done (which can be used for bottom up estimation if need be)
  • Groups a set of requirements (ideally defined as acceptance criteria)

A User Story is “Done” when:

  • All the tasks have been completed
  • All the acceptance criteria have been met

Some examples

“As a user, I want a new system because the old one no longer meets my needs” is too big (probably even too big as an Epic)

“As a user, I want to register, login and manage my details online” is still too big. It should be at least three User Stories, covering logging in, registering and managing details.

For most teams even three would be too coarse. Logging in could itself be broken down into three finer grained User Stories:

  • “As a user, I want to log in, so that I can access my private information”
  • “As a user, I want to reset my forgotten password, so that I can login”
  • “As a user, I want the system to remember me, so that I don’t have to log in every time”

These are probably the size of User Story I’d suggest that most teams use. Each delivers a standalone bit of business value, can be easily understood & implemented and can be easily prioritized in a back log.

If you start to create features like “As a user, I want to enter my user ID” and “As a user, I want to push the login button”, then stop, you have gone too far !