I worked as a developer Team Leader, than we became Agile and I took the role of Scrum Master (SM). In the meantime, I've switched to Project Management, but remained in contact with Agile and Scrum, being also an Agile Coach and close to teams working in Scrum and especially helping the Scrum Masters.

When I started as SM, we were using Stories, estimated in complexity, so in Story Points. In the planning meeting, after we understood what stories the Product Owner (PO) wanted in the current sprint, we also split the Stories into sub-tasks and estimated them in hours or days. People then started taking the sub-tasks; by pulling, not by pushing.

The estimation of sub-tasks in time was a double-check between our feeling that we could do a certain number of story points based on our average velocity and on the other hand the reality of the current sprint. Maybe some task needed a specific skill or whatever.

And then, we were using the Sprint Burndown chart in JIRA, set to show Remaining Time instead of Remaining Story Points. By doing so, the Burndown chart was going down and was really showing progress. If we were to display the chart by Remaining Story Points, it would've been a flat line until almost the end of the sprint.

What is your opinion on this estimation on sub-tasks in time? I still see it being very valuable, although as an Agile Coach I'm not pushing the Scrum Masters to use it, only recommending it and letting them decide if it is helpful or not.


If we were to display the chart by Remaining Story Points, it would've been a flat line until almost the end of the sprint.

This is its own problem. It sounds like you are making insufficient use of swarming. If you work together on and finish Story A before you start Story B, which you finish before you start Story C, then you shouldn't have a problem with your Burndown.

Indeed, I would say that right now, your Burndown is doing its job, showing you a problem in your process. Changing to Time Remaining will only hide that problem from view.

Regarding estimating time for subtasks in addition to story points for Stories, I see no problem with it if and only if it is being used exclusively to aid in the story point estimation (as a sanity check, as you suggest). In which case, once the Story is estimated, you should throw away the subtask estimates. There are good reasons why Stories are estimated in points instead of hours, after all.

| improve this answer | |

"If we were to display the chart by Remaining Story Points, it would've been a flat line until almost the end of the sprint."

Not really a problem with story points burn-down. You just have a work in progress problem. Work together on less stories.

Your current situation puts you at risk of delivering nothing (multiple incomplete stories == nothing) if things go badly. Also, you don't have the ability to replace a story mid-sprint if priorities change, since everything has been started. Also, if you have testers (I'm not necessarily saying you should) it also puts all their work at the end.

I don't subscribe to task estimation for two reasons. It's subject to a lot of change, generally tasks are discovered or (and this is a great thing you don't want to de-incentive or make into a hassle) larger tasks are split into smaller parallel ones. It also doesn't track delivered value, which is the thing we're truly interested in.

Instead, use story point burndown and make it look better. The behaviors you have to engage in to do so include making stories smaller and working together more, these are things that will improve your process.

| improve this answer | |
  • thank you for your answer. we know stories should be small, to be able to be completed (dev, tst, ops) in 2-3 days, but that is not always the case – Razvan Grigorescu Apr 28 '17 at 7:34


Changing your method of reporting will not actually address the underlying process issues implied by your original problem statement. Your old reporting process was actually the better one. You should go back to it, but adapt your team's process to optimize for achieving the Sprint Goal rather than for velocity or trend-line reporting.

Remaining Time: An Often Misleading Metric

And then, we were using the Sprint Burndown chart in JIRA, set to show Remaining Time instead of Remaining Story Points. By doing so, the Burndown chart was going down and was really showing progress. If we were to display the chart by Remaining Story Points, it would've been a flat line until almost the end of the sprint.

This is a tool-driven project smell. You're "hours remaining" is really just a variation of consumed story points, which is a misfeature I've discussed elsewhere. In other words, hours remaining is based on initial time estimate - hours expended but there's actually no guarantee in your system that the end result will equal zero. Put another way, you have three possible states with your current process:

  1. initial time estimate - hours expended < 0

    You've overestimated your story. This isn't a tragedy, but may impact the resources available for other stories/tasks.

  2. initial time estimate - hours expended = 0

    You correctly estimated your story. Yay!

  3. initial time estimate - hours expended > 0

    You underestimated your story. It is likely it will be incomplete at the end of the iteration.

Only in the second case will your "percentage complete" calculation really be accurate. The rest of the time, you are simply creating a false impression of progress where "x% of the work is y% done." Don't do that!

Work in Progress Limits and "Swarming"

Your problem is a process problem, and is likely being caused by ignoring (or simply not having) Work-in-Progress (WIP) limits. While a team can work on more than one story at a time if the stories meet INVEST criteria and are independent of one another, having team members working on stories independently of one another (instead of as a team) often defeats the purpose of having a cross-functional team. It also frequently results in other queuing and integration problems, especially towards the end of a Sprint.

In general, team members should be actively collaborating on stories, which means that as a rule of thumb your WIP limits should be around half your team size. Given a team of seven people, plus or minus two, that means your WIP limit should be roughly three stories in progress at any one time.

Since the team only succeeds if the Sprint Goal is met, doing more stories as once doesn't actually benefit anyone. It's much better to use techniques like pairing or swarming (where the whole team "swarms" over a story) to maximize resources allocated to getting a story to 100% of the Definition of Done as quickly as possible. When you work this way, your burn-down chart will more accurately show user stories or story points completed towards the Sprint Goal, and the chart will correctly burn down, up, or flatlined in a more sensible way throughout the Sprint.

NB: Remember, even if you don't complete 100% of the stories, you may still meet the Sprint Goal! The point of a Sprint isn't to inflate velocity, it's to deliver on the Sprint Goal. Optimize for that instead.

Decompose Stories and Tasks Further

If you're dealing with user stories that span the whole Sprint, they're probably too large. However, that's a judgement call; it's certainly possible to have larger stories, so long as the story fits into a single Sprint.

Tasks, however, should be roughly 1/2 to 2 days in size so that they are clearly done or not-done. If a task isn't on-track to be done within the time-box, it's worth reviewing the task to see if it needs:

  1. Re-estimation of the task or story.
  2. If there's hidden or unplanned work that wasn't accounted for.
  3. If there are resource constraints or process bottlenecks that are impacting delivery of the task.
  4. If there are unexpected dependencies.
  5. Replanning, either within the Sprint if it's minor and won't impact the Sprint Goal, or as part of an Early Termination and a return to Sprint Planning.

While stories can theoretically span an entire Sprint, tasks that require extensive periods of time are most often the result of improper granularity and a lack of task-level planning during the second half of Sprint Planning or subsequent just-in-time planning sessions within the Sprint. While implementation decisions should always be deferred as late as possible, Scrum doesn't do away with task-level planning; it just postpones it until the last responsible moment.

Use Metrics Properly

Finally, remember that velocity is a capacity-planning metric, not a measure of productivity. Likewise, burn charts are tools for identifying process bottlenecks or hidden process problems, not status reporting or task-level schedule estimation tool.

What the chart actually tells you is whether you are likely to complete all planned work within the time box, or whether your estimation or planning is out of reasonable tolerance. In other words, it's a check on your process, not a measure of productivity! In your specific case, the old burn-down chart was clearly telling you that you were not completing stories with a reliable cadence, and were likely experiencing "end of Sprint integration madness" as all the suddenly-completed stories were marked done and then (hopefully) integrated at the last minute.


I would strongly recommend going back to the old burn-down chart, and revising your process to incorporate WIP limits and swarming to fix the process problems, rather than using a new (and potentially misleading) reporting tool because you like the trend lines better. Fix the process, because working features are the real goal, not trend lines or pretty reports.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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