7

During the sprint planning meeting, does the team estimate time for each story, or the tasks that make up the story? Then which is tracked by the team/scrum master?

I assume the team estimates the time for the tasks that make up a story, then the story is the sum of the tasks.The burndown chart (if based on time) is based on the time left for stories...

Is this correct?

Improve this question

1 Answer 1

Reset to default
5

TL;DR

While there's no formal requirement, common practice is to estimate user stories with story points and tasks in units of time. There is no canonical formula for converting story points to ideal hours.

Story Point Estimates vs. Man-Hours

Story points are relative level-of-effort estimates. They typically measure whether a given story is bigger or harder than some other story. Story points are great at leveraging your team's cross-functional knowledge and the current size of your cone of uncertainty to provide a metric suitable for filtering what stories should fit into a given iteration, but they don't really say much about time.

A common Scrum practice is to use story points and historical velocity to determine which stories to accept into the current Sprint during Sprint Planning. Then, the second half of Sprint Planning is devoted to converting the stories into tasks on the Sprint Backlog.

It's at this point that time often enters into the planning. Some teams provide actual time estimates for each task, while other teams may simply ensure that no given task exceeds some maximum size (often two calendar days or some equivalent number of ideal man-hours). The purpose of this decomposition is primarily to ensure that tasks are done or not-done in a timely way, and to allow the team to "fail early" when a task ends up being larger or more complicated than expected.

Burn-Down and Velocity Units Should Match

If your velocity is measured in story points, then your burn-down chart should be, too. Rolling the aggregate time estimates from the Sprint Backlog back up and comparing the sum to your Sprint length can act as a sanity check that you haven't under-estimated your stories, over-committed your resources, or exceeded your team's capacity for the iteration, but the comparison is a process control rather than a required Scrum artifact.

While the reality is that each iteration has a finite amount of time, the nature of Scrum lends itself to a lot of horse-trading during Sprint Planning and within each Sprint. The underlying theory is that while the Sprint Goal is immutable, the individual tasks needed to complete each story may be changed, added, or discarded as needed by the team. Because of the rate of change in tasks, task-based time estimates are generally unreliable for agile planning purposes.

Mike Cohn's Agile Estimating and Planning may provide you with a greater understanding of the differences between deterministic estimates and agile estimation practices. It's certainly worth reading, whether or not you drink the agile Kool-Aid.

Improve this answer
3
  • 3
    Adding to CodeGnome's answer, my professors taught me that software project estimates should start with size, from which is derived effort, then and only then do you derive cost and schedule. This is because if you jump to cost/schedule you lose sight of what the inputs are. Old school methods included kSLOCs or function points. These days it's story points. Same idea: start with size, then derive. I prefer story points to ideal days because the latter get confused for schedule estimates.
    – Jacques Chester
    Aug 9, 2013 at 0:17
  • @JacquesChester +1 for the insights. Don't forget complexity and uncertainty, though. In my experience, where size, complexity, and uncertainty intersect typically defines the level-of-effort required.
    – Todd A. Jacobs ♦
    Aug 9, 2013 at 0:22
  • Well a personal pet peeve is in giving single-point estimates and then relying on the law of large numbers to "fix" the overall estimate, because that will conceal complexity, risk, uncertainty etc. If you use an estimate-error measurement like MAPE you can get a better sense of how wrong an estimate was. I wrote an article about it a few weeks ago.
    – Jacques Chester
    Aug 9, 2013 at 1:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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