Capacity, Tasks and Hours

Stop thinking of capacity in terms of hours. Stop estimating task duration in hours. Stop planning sprints to achieve “full personnel utilization” (again in hours). Such thinking is a holdover from the steam-engine era project management mindset, when people needed to be told what to do and when to do it. It is not how Agile teams work.

What is Capacity for Agile Teams?

“Capacity” for Agile teams is their velocity (in relatively-sized story points) for Scrum teams, or their throughput (from cycle time) for Kanban teams. Both are measures of accomplished work output. That is, they indicate how quickly the team can deliver value. More importantly, each is an emergent measurement.

Emergent Measures

An Emergent Measure is one that is derived from facts. It is not based on plans, wishes, “percentage completes”, mandatory overtime, assigned work, or pounding shoes on tables. It comes from historical data. It comes from an honest acknowledgement of reality as it is.

An emergent measure emerges from accumulated data. It has statistical variation based on history. A scrum master’s concern is first to provide space and time for the team to get variance under control, and then to improve.

Capacity is derived from Working Software

The agile principle of “working software” is seen every day during the team’s standup, when each team member describes the work they completed. This is most easily done in terms of the tasks they have done. No customer cares how many hours were spent on a task. They only care if something was done or not. Do not waste time updating “hours spent” and “hours remaining”. That is no better than waterfall’s “percentage complete”. The only thing that matters is what is actually complete.

The Yoda Rule

This leads to the "Yoda Rule". By planning and communicating in terms of tasks to do and tasks done, the team thinks at a level above “how long” something will take and instead focuses on why it might take that long – because of the tasks that need to be accomplished.

If a story is blocked – tasks are not completing in a day – “hours left” means nothing. It does not communicate anything to team members who might swarm to help. The first question they will ask is “what needs to be done”?

Use Tasks in Sprint Planning

During Sprint Planning, stories should be broken down into less-than-a-day-long tasks. New teams will have to learn what this means. Experienced teams know the cultural norm: A task is what your peers won’t laugh at when you report completing it at the next stand up. (A legitimate accomplishment to describe at standup is the discovery of additional tasks that must be completed).

This will give a task count. Throw away your hours-based burndown chart and use a task-based burndown instead. This has the added advantage of making conversations with the Product Owner more meaningful. Instead of saying “we have 100 hours left”, you say “we have to do X, we have to do Y, etc”, giving the Product Owner a chance to say whether they really intended you to do X or Y.

Use of Hours is a Cognitive Fallacy

Humans are linguistic creatures. Humans are semantic creatures. Humans do not communicate well, if at all, in numbers. Humans do not think in numbers. That is why we use stories to describe the work to do. Humans do ok with relative comparisons (hotter/colder, bigger/smaller). Humans do ok with relative time (longer/shorter, before/after).

Using the semantics of task description to communicate work leverages humanity’s 50,000 years of storytelling experience. The tasks of the stories in a sprint form a narrative for the sprint. This narrative should make sense to the team.

Planning in hours is “magical thinking”

If you are an executive, a manager or a scrum master who thinks you need to see hours you are engaging in magical thinking. You have an Illusion of Control – that if a task is estimated to take X hours it will actually be done in X hours. The reality is, until it is finished it is not done. That’s it. Simplistic, but easy to understand. Don’t waste the team’s time overthinking this.

This illusion is hard to give up. 

But it up you must give, as Yoda might say.