It's likely that your process issues are a result of the following Scrum implementation errors:
- You're treating estimation as a team activity, but task performance as a solo activity.
- 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:
- Only the task performer can properly estimate his or her own work.
- All work collectively belongs to the team.
- Stories and tasks should never be assigned to an individual.
- The team itself should determine which team members (and it may be more than one at a time!) should be responsible for each task.
- 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:
- "I expect to have Task A done by lunchtime."
- "I expect to have Task B done by the standup tomorrow."
- "Alice, will you be able to finish Task C today in time for me to finish Task D?"
- "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?"
- "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.