11

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?

|improve this question
  • 1
    If you are struggling to meet your sprint commitment then you should reduce how much you put into each sprint. Keep on reducing it until you have no trouble hitting your sprint commitment. Then you have reached the true capacity of your team. – Barnaby Golden Oct 5 '16 at 19:48
  • Also remember that it is a forecast as unknown can be discovered. – Alan Larimer Oct 6 '16 at 13:42
  • Sprint backlog is not committed but forecasted(!). One way how to decompose stories is to write acceptance criteria for them and then look if some of the acceptance criteria can be transfer to user story. – MasterPJ Oct 14 '16 at 12:24
14

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.

|improve this answer
  • 1
    Just thought I will add a simple fact here, the more granular you make your story it becomes more easily and quickly testable. So when you write down your story/task, encourages QA to think about testability, how quickly they can finish testing, any dependency on other tasks and so on (factor in the time if you have to resolve them). This way you will reduce the gap between estimates and actuals. – Mincy George Oct 14 '16 at 12:37
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!

|improve this 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. 😀

|improve this answer
  • I just started using the Give/When/Then format of detailing out my user stories and I've found that its a useful tool for letting me know when a story is getting too big. When I start getting too many AND, OR & BUT statement, time to go back and re-scope the user story so it can fit more neatly into a tight G/W/T statement. – Stewart Whitman Jan 31 '17 at 23:21
1

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.

|improve this answer
1

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.

|improve this answer
0

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).

|improve this answer
  • This is how we are estimating and most of our estimate are 1 or 3, so by this measure we are estimating correctly. Except we aren't getting the work done. We are a team of 7.5 ( one part time) and velocity bobs around from low to high teens. We are definitely over committing our sprints, but I feel like there is more to it like mis-estimating stories that are non sufficiently granular. I like what Rubber Duck said. We are also going to try doing more consensus estimating with the entire team. Right now estimates are provided by individuals and not the team (a practice I inherited). – Stewart Whitman Oct 6 '16 at 11:21
  • 1
    In that case, it sounds like your baseline (the 1-point stories) is too large. They should be broken up if possible, or estimated higher if not. Either way, you need a smaller baseline. Also, yes, since it is the Team who make the commitment, it must be the Team who estimate. Make sure it's not done in a way where the loudest has the most weight, either. Planning Poker works well. – Sarov Oct 6 '16 at 13:24
  • 1
    We are going to try something similar to planning poker. The difference is we organize the stories on a pin board and the team has to arrange them into columns based on size. The ones that are controversial and can't seem to find a home, are ones where we will see to gain clarity and continue to drill down in size. – Stewart Whitman Oct 7 '16 at 14:58
0

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.

|improve this answer

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.