In agile (scrum), how do you go about breaking down a user story?

Question

In agile (scrum), how should one ideally break down things into a user story.

The team size is about 6 developers if that makes a difference, and iterations are 3 weeks.

Is breaking a user story with points and hours considered agile, or is it ONLY user points for a given user story?

Should we break a user story into tasks also?

In the actual workflow for a user story, you have things like:

1. requirement gathering
2. review of the user story by managers etc.
3. qa related tasks in the user workflow

How are these things handled in a agile environment?

Answer 1

A user story is typically created from a need expressed by the client or potential user of the system. It's often of the format "As a {role}, I want {goal} so that {benefits}". The collective set of user stories capture the functionality desired in the system that is being built. The customer or customer representative prioritizes each user story, typically based on the value added by having the functionality specified in the story.

Once written, user stories are sized and estimated. There are a number of techniques to do this. The most common method of estimation that I've seen is the amount of effort needed to complete the task, in arbitrary values. There's a base unit that everyone can agree on, and use this as a common framework for providing estimates as to the effort required. I've seen these as being unitless values called "story points", but I don't see why you couldn't also estimate the user story in hours. The key is to be consistent across all user stories.

For the first iteration, the team estimates how many story points they can complete in a given iteration and move up to that number of points into the backlog for an iteration. If you are estimating in hours, then you can determine how many hours your development team will dedicate to the project during the iteration and pull down that many hours worth of work. After the iteration, you determine how many points or hours that you actually completed and pull down that amount of work for the next iteration.

During the entire process, your overall backlog of stories is changing. Features might be removed, new features can be added, or the priority can be changed. However, none of this affects the work that was pulled down for the current iteration. Only between iterations should you adjust what you are working on. You will typically either have an on-site customer representative or someone who can act as voice of the customer and is in contact with the appropriate people from the customer's organization. They are continually refining the requirements and acceptance criteria throughout the project.

How you further break down user stories into tasks is up to you. It might be an undocumented preference of the engineer, or there might be a detailed analysis of exactly what each user story entails. That's something that needs to be specified by tailoring the process to meet the needs of your organization, team, and project.

You should have a definition of done, which can be used to determine when a particular user story is shippable. This defines everything from design, implementation, testing, quality assurance, acceptance criteria, and documentation. You can specify what tools and methods you use to ensure that a given feature as specified by a user story is done. Once a user story is done and integrated, the product should be in a potentially-shippable state, meaning that packaging it and delivering it to the customer would add some value to their operations or meet some of their needs.

Ultimately, you need to tailor the processes to work for your organization, team, and project. Doing anything "by the book" is usually a recipe for problems. Just because something has been documented and works well for certain teams working on certain projects doesn't mean that it fits everything that you need it to do.

You might be interested in this InfoQ article on user story estimation as well as Scott Ambler's Introduction to User Stories.

Answer 2

It is Agile, in that it conforms to the Agile manifesto.

It is not Scrum, in that Scrum suggests you should use complexity points to estimate everything.

But neither of these things are that important. In fact, I argue that strict adherence to Scrum, despite all evidence that you shouldn't be, is not Agile.

Here's the question you should be asking: is it useful to you?

How does it improve the process of getting the job done? What does it offer in terms of visibility? How does it help your users get the product they want? What does it offer to quality?

If you can't answer those questions then don't bother doing it. If you're not sure then try it, measure, adjust accordingly.

Answer 3

Where I work we have a couple of different conditions that will cause a story to be broken down into multiple stories:

1. The poker points for it are too high or the story seems too vague to even try to estimate. If the story has more than X points, then it is too big to treat as one story to get done in a sprint. This prevents the team from being overly committed as sometimes a big story can be hard to estimate how many hours it'll take and how fast can it really get done. "As a site visitor, I want to buy products so that I can have those products at my home," would be the type of story that is just too vague. Amazon.com wasn't built in a 2 week sprint.

2. Getting the story done in a sprint doesn't seem likely and there is an easy way to split the story into multiple parts. For example, a first part may be to investigate and design a solution. Another part is to implement that solution. Each part can be done in a sprint but it doesn't seem likely to get both done in the same sprint.

Sometimes it may be in seeing the task list that goes with a story that will show that it falls into that second case or that there will be so much QA required as some major piece of functionality gets rebuilt that the story has to be subdivided.