What Is the Right Size for a User Story?

A question that comes up again and again from teams is “What is the right size for a User Story?” -- a day? a week? three weeks? 1 point? 5 points? 10 points? 37? 100? 5 words? 20 words?

Short answer: There isn’t a universal right size for a User Story; it depends on your team, their skills, and their level of domain knowledge.

Long answer: For some teams, a User Story is Big, several days or weeks of work. On other teams, they are small -- maybe a day’s work. Both are possible; both are the right answer.

Although, as a general rule, smaller is better.

For me there are criteria that a User Story should meet:

• It should be small enough for the technical team to understand and create in a short time period.
• It is small enough to move on the board sometime soon.
• It should be big enough to represent business value in its own right -- it might build on something that has been done before (e.g. a lower fidelity version of the same story, the new one increasing fidelity).
• It is big enough to be deliverable in its own right -- you might not want to do so but if you needed to you could.

In an ideal environment, the story would be developed in a few days, would be released on its own right and the business value measured directly.

(For those who know about Minimally Marketable Features (MMFs), also sometimes called Business Value Increments (BVI) or Quantum of Value (QoV), I casually consider a User Story to be a MMF.)

When a team is dedicated to a particular product, and have worked on it for several years, and have learned about the domain -- as I would expect in for in-house development operations -- I expect to see larger stories.

Conversely, when a team doesn't know the domain -- as is common with outsourced development -- I expect to see small stories, and more knowledge pull from the client.

Taking a step back, a few basics:

• A User Story is not in and of itself a requirement; I like to call them “Tokens for Work to be Done;” others like to say they are a "placeholder for a conversation” -- both are true.
• Don’t feel that you must use User Stories; if the format doesn’t fit your need then don’t use it! You can still have a “token for work to be done” and a “placeholder for a conversation” using any words you like, -- they don’t have to be “As a… I can … So that…”
• The User Story format does capture three very important elements: Who, What, Why so they make a good starting point and are easy to understand but if they don’t work for a particular need then don’t force it into the format.

Small stories are better -- they can be developed more quickly, delivered more quickly, and return value more quickly. But there comes a point were stories become too small to return any business value at which point they, well, loose value. Plus, when you have a lot of small stories they become a headache to manage.

One common problem I see is teams who create really small stories in order to get them to fit within one sprint. This means large stories don’t get scheduled or teams split large stories into many small ones, which have no business value themselves.

People say this is a Scrum thing; I’m not sure. Scrum doesn’t mandate User Stories -- the story format came along after Scrum. 

What Hard Core Scrum does say is that all the work the team commits to should be done by the end of the Sprint, which would imply a story has to be small enough to fit in the Sprint.

The problem then becomes: What else do you put in the Sprint? If one story is going to take more than half the Sprint, you need one or more stories to use the rest of it up. Plus, you hit the commitment problem -- developers have an incentive to under commit and the business/custom has an incentive to over demand.

My solution -- one which I’m baking into my description of Xanpan -- is:

• Stories are split into Tasks during the planning meeting.
• Tasks do not follow any particular format, nor do tasks have any business value.
• Tasks are for the team -- the developers, testers, analysts and anyone else.
• Tasks should be small, a day or two at most.
• A story is not done until all the tasks are done. Stories can therefore flow across iterations; the chances of tasks flowing across iterations is low (because they are small) but they can and do.

However -- and this is the key point -- in counting the points (velocity) of a team, only the completed Tasks are counted. Partially done tasks are not. The only states that matter are Done and Not Done.

As I’ve written before, the breakdown of stories to tasks fills (at least) three purposes:

• It is superficially an estimation exercise.
• It is also a requirements elicitation process (I like the Requirements Engineer, BA, Product Owner/Manager to be present).
• It is a design activity.

You know a task is too big because it is difficult to finish. If it is difficult to finish, it needed more thought up front, to define and understand it, to bound it, to understand it. (See the mini-series on Story Points earlier this year, and specifically the Story Breakdown entry.)

So there you have it: There is no right size of a User Story.

That said, they may still be “too big” or “too small.” But what constitutes right is dependent on you, your team, and how you play the game.