Breaking down user stories

A user story is a short, simple description of a piece of functionality, as told from the perspective of a customer. It's intended to form the basis for a discussion about how to provide business value, and it should be relevant to the customer. "I want to be able to download my calendar data" is a good user story; "refactor the back end" is not.

A task is an distinct, actionable activity of short duration:

• Distinct: a task is one well-understood thing. They're not big, ill-defined things and they don't have "and" in the title (that would be two tasks!).
• Actionable: it's something you can do. "Get calendar data from database", "add SSL bindings" or "write documentation" are actionable. "Program to ISO 3103 standards throughout" is not.
• Short Duration: a task should take between 1-6 hours. If it's longer, then you need to break it down - it's not distinct enough.

Stories are estimated by relative sizing; by using arbitrary values (such as T-shirt sizes S,M,L,XL or the Fibonacci sequence) to indicate which are larger than others. Tasks are given absolute sizes in hours. This reflects the amount of accuracy involved at each stage - with a story you only have a rough idea of how difficult it's going to be to deliver what the user wants, when you're creating tasks you know exactly what you're going to do.

User story: business value - what, why.
Task: technical description - how.

How to break down a story

Think of breaking down a story into tasks as recursively asking the question, "how am I going to make this happen?" until you get to a distinct, actionable task that you can complete in 1-6 hours. For example:

Don't forget about tasks beyond writing code!

• Code Review
• Documentation
• Testing
• Deployment

These can also be broken down if necessary. If testing is going to take more than 6 hours, you might consider splitting it to, "write test cases", "test functionality", "test cross-browser compatibility" and so on.

What if I discover something else that needs to be done mid-sprint?

Simple: create a new task, estimate the number of hours, and add it to the story. This could cover everything from simple bug fixes to realising your initial ideas won't work and you need a complete change of direction. Discovering new work is inevitable - the important thing is making sure it's tracked.

Why do this?

The reason for doing all this work is twofold:

• Understand what you're going to do in the sprint
• Be able to report on how well things are going

The first is important - it's one of the (many) things a people often get wrong about the Scrum process. It means that before you start a sprint, you know what you need to do to meet your chosen goal - what needs to be implemented, what needs to be learnt or tried for the first time, what your risks are and even simple metrics like whether there are too many or too few hours of tasks for the time available. Each story is well-understood, and everyone on the team knows what's going on.

The second goes even deeper to the heart of the Scrum ethos. When you have well-estimated tasks of only a few hours apiece, you can get down to day-by-day tracking of progress against a backlog. That means you know well ahead of time if the sprint goal is in jeopardy, or if you're ahead of schedule. Also if you need to add new tasks (and it does happen) you can see the impact on your sprint burn-down immediately.