Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
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?
You have to balance two competing needs in project management: the need for accuracy and the need for flexibility.
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........)
It's likely that your process issues are a result of the following Scrum implementation errors:
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.
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:
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.
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:
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.
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.
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.
