4

My team is adopting Scrum. When estimating story points for a backlog item, we use planning poker to reflect the team's average vision of the story's complexity.

When estimating task hours within a story, should we plan based on the capacity of the person executing the task or on the team's average capacity? What happens if someone who is slower assumes that task? Should we then re-estimate the remaining work?

  • 2
    Please avoid cross-posting across StackExchange forums. You may want to close your posting in StackOverflow. – Barnaby Golden Aug 19 '16 at 7:11
5

You have to balance two competing needs in project management: the need for accuracy and the need for flexibility.

  • Calculating task hours based on the executor's capacity will likely be more accurate.
  • Calculating task hours based on the team average will under/overrun depending on who is performing the work, but you gain flexibility because ALL of your tasks are computed using the same average.

As always, reality is specific to your situation. You, as the PM, must use judgement on the likelihood that another developer will take over a task once it's been assigned, then use the hours-calculation method most appropriate. This decision can also be dependent on your customers/stakeholders and their requirements for accuracy vs flexibility.

My suggestion is to choose one method and go with it. Review the accuracy of the estimates over the next few sprints and gauge its efficacy then adjust your methods as needed.

If you have a customer who is pushy on this topic, simply state your methodology and your plan to adjust. Good project management is about making a timely decision and implementing it and then reviewing the effects of the decision and adjusting as necessary. (It never really ends........)

  • Statements such as "You, as the PM, must use judgement on the likelihood that another developer will take over a task once it's been assigned" and "Good project management is about making a timely decision and implementing it" sound like classical command-and-control management and not agile software development. Within the Scrum framework the Development Team self-organizes and makes all estimates. More important than attempting to have correct estimates is to learn from the results of the Sprint. – Alan Larimer Aug 20 '16 at 17:16
  • This OP was posted on the Project Management SE site, so I answered from the point of view of the PM. For good or bad, most agile teams I've been associated with have turned to the PM for this type of guidance. There's a strong argument there that these teams are not "true" agile or Scrum, but from a philosophic point of view I've always believed the scrum master/team leader/PM is a responsibility that is oftentimes shared by more than one team member. Having said all that, globally replace "PM" with "SM" and I believe my answer still rings true. – PeterT Aug 20 '16 at 18:06
3

TL;DR

It's likely that your process issues are a result of the following Scrum implementation errors:

  1. You're treating estimation as a team activity, but task performance as a solo activity.
  2. You're trying to assign ideal hours at the task-performer level, rather than focusing on collaborative estimates at the team level.

Don't do those things. Estimate stories collaboratively, and time-box your stories and tasks rather than spending time on the chimera of task-level precision.

Don't Intermingle Group Estimates with Solo Assignments

You have created a false dichotomy between estimation and task performance. When you ask:

When estimating task hours within a story, should we plan based on the capacity of the person executing the task or on the team's average capacity?

you're violating several interconnected principles of effective Scrum implementations. Specifically:

  1. Only the task performer can properly estimate his or her own work.
  2. All work collectively belongs to the team.
  3. Stories and tasks should never be assigned to an individual.
  4. The team itself should determine which team members (and it may be more than one at a time!) should be responsible for each task.
  5. The team should collectively swarm over a story or task that has exceeded its time box.

In other words, the underlying problem is that you're treating estimation as a team activity, but task performance as a solo activity. Don't do that.

Story vs. Task Estimates

You're also creating a false comparison with your estimation practices. Generally, teams collaboratively estimate Product Backlog Items (PBIs) such as user stories, but effective Scrum teams rarely decompose stories below a half-day, and typically don't estimate tasks at all.

While you can certainly find some support in the literature for estimating PBI tasks in ideal hours, doing so is often orthogonal to agile estimation, which relies on statistical averages over time rather than on an artificial (and often misleading) level of precision. Can you really forecast most human-driven tasks accurately enough to justify the overhead of estimating them individually? In the software world, at least, the answer is usually "no."

In general, you should play planning poker (or use some other team estimation technique) on user stories. Since stories are either done or not-done, there's rarely value in estimating the tasks at all, and almost never as a group.

In the rare edge case where there is some sort of value in estimating individual tasks, you should leverage the daily standup to enable the team to coordinate tasks within a 1-2 day time box. Some examples of this coordination are:

  1. "I expect to have Task A done by lunchtime."
  2. "I expect to have Task B done by the standup tomorrow."
  3. "Alice, will you be able to finish Task C today in time for me to finish Task D?"
  4. "Bob, you weren't able to complete Task Q yesterday, even though you thought you would. How can the team work together to get it finished today?"
  5. "We have two days left in the current Sprint, and won't have time to finish Task Z."

Focus on getting stories done at a sustainable pace, rather than on whether specific task-level estimates are precise to two decimal places. When done properly, this will generally improve the overall accuracy of your estimation process, as counterintuitive as that may seem. And even if it doesn't improve accuracy, at least you won't spend an inordinate amount of time trying to assign a fallible level of precision to things.

1

When you do planning, better to go with Team's average. When task is owned by each individual, it should get sorted out.

Other perspective is that, For team also, you can't have major difference between individual + team's average. If so, there will definitely other overheads like attitude issues, etc. When there is one hyperactive, there will be totally opposite to that as well in the team.

1

What do we know about time estimation? It is inherently inaccurate for complex cognitive work regardless of what method is utilized. Thus the preference for relative sizing. Estimates are really best guesses. What really matters is the empirical data that can be gathered after work has been completed.

Sprint Backlog progress can be measured by various methods. As long as understanding of how progress is measured toward the Sprint Goal is Transparent, it doesn't matter what units of measure are used. Some alternatives are number of tasks, Product Backlog item estimates, number of Sprint Backlog items.

Regardless of method, an initial estimate is be made by the Development Team. As each task is picked up by a Development Team member, and throughout the Sprint, that value should be updated to measure progress toward the Sprint Goal. After all, that is its purpose.

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.