User story size/scope

Question

When doing agile what are the specific criteria of defining the scope of a user story? What factors should I take into account when defining the scope? Is there any specific formula you use for this purpose?

Answer 1

A "User Story" in extreme programming is supposed to be the smallest possible unit of business value.

Some handy suggestions for rules:

• User stories should only ever be written directly by the business. We want them engaged and to feel a real sense of ownership.
• All stories are supposed to have some kind of business value attached - even technical stories like "make the listing page return faster" - need some kind of business value like "in order to meet the rush for Christmas orders we need to return the listing page in less than 3 seconds for 2500 orders".
• The template that I've often used (and seen people like Rachel Davies use) is

"As a stakeholder-name I want to action-description so that business-reason-why"

• Each user story should have some kind of acceptance test. When you're writing the story you should think about the criteria for completion, but you work out the acceptance test details as part of the iteration in which the story is scheduled - just make sure you do it first. (It's a common mistake to leave the acceptance test 'till last and then find out that the implementation isn't quite right...)
• Technologies like FIT, Fitnesse, JBehave, Cucumber,... are a useful way of writing executable acceptance tests for user stories in a form the customer or domain expert can understand more easily.
• Extreme programming really does work better with real, physical index cards. It's so easy to get bogged down in a complicated electronic system that becomes it's own subproject. If you really have to have an electronic form, get somebody to type of a list of completed stories, incomplete stories and not started stories as an end of iteration summary.
• A user story is a "token for a conversation". User stories should be concise and minimal. Don't think of them as a "specification" - just a reminder of what we need to do. (This is why they chose to write them on index cards - you can only put so much on one.)
• If you can't fit all the text on a user story card - you probably need to split the story, or simplify it somehow
• Some people actually ban writing urls or tracking ids into bug databases or specification tracking systems because that can become a route back to waterfall thinking - i.e. writing all-encompassing requirements docs.
• Nobody is allowed to attach papers or documents to a story card. Again, we don't want to encourage people to write specs - better to talk to the customer and use code-based acceptance tests.
• Treat words like "and", "also" and phrases like "in addition to" with suspicion on a user story. It's very easy to break the discipline of keeping each story as down to the smallest possible unit of business value and it takes vigilance - especially when under pressure to fit more into each iteration.
• You should always be able to complete a story within a single iteration. The story is either too big, or not properly estimated or there's some other kind of problem if it doesn't fit in a single iteration.

Answer 2

Stories shall bring value to customers, and have acceptance criteria so that it's easy to know if a story is complete.

Also, size matters here, the team shall be able to complete between 5 and 10 stories in on iteration.

If necessary, user stories can be split or grouped.

Answer 3

This is a great question. The key to doing it well is great collaboration between the PO and the team. The PO owns the backlog and is the only one who keeps it updated. But the team has to provide him/her feedback to be able to build it out effectively. I find that if the PO and tam haven't worked together before it takes a while to get used to what "size" story the team can accomplish in a given period of time and thus at first a lot more collaboration is required.

I think the ideal story takes 2 days of team time or less. Obviously based on your team size and ability more or less complicated stories can get done in that period of time. My current team is small (3 dev 1 test) so we find that anything scored 8 or higher is suspect and needs splitting because it will likely take more than 2 days.

The PO doesn't know and can't score stories so he only has gut feel to help him write the stories. So lots of time the team will have to help him re-write them smaller. This is done BEFORE the sprint planning meeting. The PO will get better over time just like the team at estimating size and will be able to look back in the backlog and see what things look like what the new thing is and that will help him size them correctly. He will eventually automatically break a "Save" story up into "delete", "add new" and "edit existing" stories on his own after the team has helped him do that a few times.

Anyway, my answer is 2 days or less for every story.
Factors to account for are team size, team ability, product type.
Formula is 1-x story points -> good story; >x story points -> too epic. Where x is your team's 2 day threshold.

Answer 4

Since all of the answers here have some useful remarks in them, I decided to sum the whole thing up and add a couple of my own ideas.

First of all, there are couple of constraints that have effect on how to scope the user stories:

1. There has to be at least some business value delivered after each sprint.
2. To really prove that the value was delivered, every story has to be accompained by a definition of done, which means there has to be some way of demonstrating that the feature is working, which in more technical terms translates into presence of acceptance tests for every story.
3. Since there is always a risk of not delivering all the sprint backlog items after the sprint, each of them has to have some business value per se, so at least some business value is going to be delivered.

Based on these constraints we can infer some rules:

1. Make sure the product owner is involved very tightly in the story definition phase, since he is the one who decides whether it has or hasn't any business value to him. However, since there has to be at least something delivered, make sure you cooperate with the PO during the story definition phase so that the stories have reasonable size and at least some of them are really going to be delivered on time.
2. Write acceptance tests for every story up front (during the sprint planning phase).

3. To make sure that at least some business value is going to be delivered at the end of the sprint, make sure that the number of stories in the sprint backlog is proportional to the size of your team.

   What does it mean that the number of items in a sprint backlog should be proportional to the size of the team? Here are some ideas that could hold true for some really small teams (2-10 people):

   If you have a small number of people (say two as the most extreme model situation) on a team and the sprint backlog consists of only two items, you run a high risk of not finishing any of them. In other words the story size of one sprint is not acceptable here. Having just a few stories with high story point values means that if you miss just one or two of them, you'll probably miss quite a big chunk of what should have been delivered. Other than that, if your stories aren't fine grained enough you'll run into troubles in the next sprint planning session, since you'll have no space to maneuvre (it's very difficult to add or remove a story from the sprint backlog if they are too big.) I think that a psychology of motivation could play its role here too. Battles that are small are easier to win and loosing them doesn't hurt that much.

   To avoid aforementioned problems you should probably decide upon some quite a rigid number of stories you are going to put into every sprint backlog, which means there has to be some definite maximum size for each story.

   My rule of thumb here would probably be this - loosing one story definitely shouldn't mean loosing the whole sprint. And it probably shouldn't mean loosing 50% of the delivery, too. I think loosing one story shouldn't hurt very much. When considering the scope of a particular story, one should probably ask questions like this: If we lost just this one story during this sprint, would it be very painful? Or, is it going to drag the morale of the whole team down rapidly? If the answer is positive, the story is probably too big for the size of the team.

   If you have say 100 points in you sprint backlog and loosing 20 points during the sprint would mean a catastrophe, you probably shouldn't have stories bigger than 15 points in your sprint backlog.

   I was trying to come up with some more precise formulas, but at the end I just decided to go with 6-10 stories per iteration for our small team with the maximum size of 1.5 days (as some other people have proposed here), since it seems to be in consonance with what I was trying to state here.

Answer 5

As for figuring out what specifics you need to include, talk to the team—if you give them a rundown of the user story, they'll ask you questions that you can add to specific requirements for completing the user story. At my office, we have weekly meetings (aside from sprint planning) where we take 30-60 minutes to look through stories on the backlog alongside the PM, giving the team a chance to clarify any ambiguity and size the story.

We look out 2-3 sprints worth of work, which gives the PM plenty of time to reformulate or break up stories if they sound to big when they're being introduced to the team.