Story Decomposition Granularity

Question

We are having a hard time meeting Sprint comits, one reason I suspect is that we are not doing a good job estimating and one of the causes of this is that we don't do a good job decomposing the story down to a sufficient level of granularity to fit within the sprint.

I see a lot of comments on Agile that it is critical to have granular stories that are small enough to fit in the sprint, but I have not found any recommendations or best practices for HOW to decompose a story to the correct level of Sub-Task granularity.

Does anyone have good practices or heuristics as to what is the "right" level of granularity?

Answer 1

Ask yourselves this one question.

Is there any possible way to do anything less, and still deliver value?

If yes, write that smaller thing down. Then, ask yourselves again.

Is there any possible way to do anything less, and still deliver value?

If yes, write that smaller thing down.

Repeat until the answer is:

No. It's simply not possible to make a smaller change and still deliver something valuable.

---

I sound flippant, but I don't mean it to be. This is an absolutely terribly difficult thing to learn how to do. But it works. It seems deceptively simple, but this is the exact process we use on my team and we've had great success with it. Think of it kind of like "The 5 Whys". You recurse into each answer until you've got a tiny piece of functionality to deliver.

---

For a pseudo real life example:

Jim, the gamer, wants a green icon 
when the battery is > 20% and a red 
icon when the battery is <= 20%,
so he doesn't kill his phone 
and miss calls. 

Woah. Wait. Does Jim really want a green icon, or does he want to know how much battery he has left?

You're right. We could just display the number for now, then add the fancy graphics later. We'll need to calculate the battery remaining anyway.

Cool. Now if we don't get around to the graphics next week, we still have something to deliver.

It's a bit contrived, but is based on a very real conversation I had when grooming a backlog with our PM & QA a few months back.

Answer 2

I often run an Agile Requirements workshop with the product team. It's fairly strait forward and easy to run. Get your entire product management team and add enough coders and testers to have all disciplines represented on teams of 3-6 people. If you need architects' or other disciplines' then include them.

1. Present Agile Requirements: INVEST, Given/When/Then
2. Let them self organise into teams
3. Get each team to choose a PBI/Feature/thing that they have previously delivers. Preferably one of the things that took longer than a sprint to deliver.
4. Give them 120 minutes to break it down into what they believe is good decomposition. Go round and question decisions, point out size and vagaries. Ask each disaplin if they believe that they can deliver each item inside of a sprint.
5. Do a retrospective
6. Generally lunch
7. Get them to select a PBI/Feature/thing that they have not yet delivered.
8. Give them 60 minutes to break it down into what they believe is good decomposition.
9. Repeat as necessary

At the end, everyone should have a better idea of what is needed, and now understand what is involved in refinement. 😀

Answer 3

1. Coach your product owner. Often you will find that Product Owner have simply cut the system they want into bite-size bits, instead of specifying which value each story delivers. Once you focus on value, you discuss how to deliver value with the smallest possible change. This is the red-battery-icon discussion above.

2. Draw all days of your Sprint on paper. Let your team plan in detail when they plan to do which story. Sprints are preferybly NOT larger than 2 weeks, otherwise too much complexity gets a place to hide itself. Stories larger than 3 days must be viewed with extreme suspicion. When a programmer plans to bury himself for > 3 days with no intermediate checks or feedbacks, he's saying 'I don't know'.

3. Use the retrospective to answer this question. Make sure you have hard data about what happened the last Sprint. No guessing or feelings. Facts!

Answer 4

One way of looking at it: if a story is estimated at an equivalent of 3 person-days or more and does not have sub-tasks, it usually means that the team does not have a clear line of sight to implementation, and the task is quite opaque.

Considering that engineers tend to underestimate opaque tasks, it usually leads to optimistic sprint plans, and hence under-delivery. We have been tracking average story size in each sprint, and observed a clear inverse correlation between story size and sprint completion percentage.

There are various methods of getting lower story sizes, and there is no magic bullet. We use a combination of:

1. Spike tasks: dedicated analysis stories, which success criteria is a reviewed low-level design, and a fine-grained story breakdown.
2. Forcing smaller acceptance criteria, as described in one of the answers above
3. Again, similarly to answers above: backlog grooming, team commitment etc.

The most effective method for us is spike tasks, though the downside is that they work best with smaller sprint sizes.

Answer 5

I agree that not being able to 'size' and therefore meet a sprint is a common issues and almost always caused by poor estimating. It's something many people try to shortcut and to their cost. You have two choices - you have to decompose stories (or whatever you are using) to a point where you can estimate them and either use hours, or simply give them a relative size against an item in the sprint that you can confidently estimate. The second method can be harder and is likely to need more of a planning poker type of approach.

I also think it is not a 'size' thing (i.e. level of detail) that gets you to the point of being able to get to 'reasonable' estimates. It is more about asking questions when you look at a feature/story the answers to which determine if you need to decompose more to get to an estimate you can have faith in.

Answer 6

There are two different approaches I've seen work fairly well. Both make use of the following sequence: 0.5, 1, 2, 3, 5, 8, 13

1) Use 'ideal man days' as these story points. For example, if it would take an average developer 3 days to complete the story, given perfect conditions (No meetings, no interruptions, perfect working environment, perfectly understood requirements, no scope creep, etc.), then it's 3 story points.

2) Pick a single, completed story that could pass as both 'typical' and small enough to be easy to estimate and set that amount of effort as your baseline (1). For any new stories, if they're about half as much work, they're 0.5, if they're about 5 times as much work, they're 5, etc.

In either case, if you aim to generally keep around the [0.5, 3] range, you should be at an acceptable level of granularity. Though, as always, mileage may vary - different people and teams will work best with different degrees of granularity. The best advice I can give is to try something, measure how well it worked, and then adjust (or accept if everyone's happy with it).

Answer 7

It's a balance between the Product Owner providing a clear picture of the requirements in the story and then the Development Team being able to take that information as well as collaborating with the PO (woah, there's a crazy idea) to discuss what work is required to fulfill those requirements. If the team doesn't know something from the "WHAT" that the PO is asking for then the PO should find out and the story should continue to be groomed. As the team begins to have feedback about what work would be required to build the requirements then they can help specify "HOW" the work is broken down. The PO should remain open to breaking stories down as that will give them the most transparency around how work is progressing once it gets pulled into a sprint.

The teams I work with have a PO that puts in as much information as they can into a story to provide the best picture of what they expect AND the value it provides. They then collaborate with the team during the estimation exercise as the developers talk through and whiteboard the work that is necessary. If something feels too big then the conversation keeps going to break it down. The team should have feedback to the PO if they feel something is missing or if the stories are too detailed (as that can happen too). Stories with good descriptions, acceptance criteria, mockups, etc. also help paint that picture.