In planning our 4th Sprint, which is currently in progress, we wrestled with determining how much backlog each individual and the team as a whole can deliver. The part that was difficult was figuring out how much cost affects each person on the team. In Sprint 3 we stated that each person had a 20% overhead cost. That is each person probably spends 20% of their time reading e-mail, sitting in meetings, or doing other non-backlog activities every day.

But we realized that some people have a higher cost because they may be required to continually perform certain duties, such as writing blogs, maintaining latest build terminal servers for the team, and so on. How can we figure out how much backlog can be delivered when we are uncertain how much time individuals spend on non-backlog activities?

We decided to track each person’s cost as part of the daily Scrum. As we go around reporting, each person states what they did yesterday, what they will do today, what’s blocking, and what percentage of time they spent actually working on backlog. The percentage is a rough estimate so that no one is burdened trying to record minute details about their day. We’ll have to see how this plays out at the end of the Sprint in our Retrospective.

Interestingly, David Anderson posted a couple of interesting articles on measuring capacity that are related to this problem. I think the solution is easier than we thought. With some personal help from David Anderson, I reached the following conclusions.

A team’s **capacity** is measured in unit values (topics in our case). So if we deliver 150 topics in a Sprint, our capacity is 150 topics. That can vary by a certain amount since the next Sprint could be 160 or 140 or more or less depending on resource availability and topic difficulty. Over the long term you should be able to establish a variance.

A team’s **velocity** is also measured in unit values (topics). Delivering 150 topics over 20 days is 7.5 topics per day.

On the Cumulative Flow Diagram (CFD) the capacity shows up as the total topics delivered on the last day of the Sprint. The velocity is more or less a straight line that starts at zero on day 1 and ends up at capacity on the last day. The top of the CFD is always the number of topics to be delivered.

In Sprint planning, you can use capacity and velocity to guide how many topics can be delivered. In a longer Sprint, velocity is the more useful number. You wouldn’t say that in a 40 day Sprint you will deliver 150 topics just like in the previous 20 day Sprint. But you could multiply 40 by 7.5 to come up with 300.

**Productivity** is an interesting question. Suppose you are asked to increase your velocity, or capacity. The manager says, “You delivered 150 topics last Sprint, now I want to see 200”. All conditions equal, the new Sprint will deliver 150, and not 200.

But if you measure your productivity each day as a percentage of time committed to the backlog, you have something to work with (the Agile community calls this load factor according to David Anderson). Suppose over the last Sprint you averaged 50% of your time working on the backlog (delivering topics). If you are asked to do more, you have to increase that percentage by dropping or changing something that contributes to the cost. You could attend less meetings, reduce non-backlog activities like blogging, or taking on special non-team related projects, or stop all those trips to the bathroom.

Anyway, I think measuring your percentage of time (load factor) is useful for improving productivity, or understanding it, but not for Sprint planning. Capacity and velocity are used for planning the Sprint.

-davech

Everyone focuses on increasing velocity, when what you really need to concentrate on is reducing variance. For example, Dell has a high velocity in that they can configure and deliver a computer in a few days. What would you rather have? A computer guaranteed to be there in 3 days or somewhere in the next 1-6 days? The average is the SAME, butthe variance is CRUCIAL. Lower the variance first, and you’ll discover how to improve velocity.

The variances we’ve seen in the past have led us to measuring velocity, which is to better understand how much of our time is spent on activities that directly support our backlog and those that don’t. With this information we can make more educated estimations of our capacity in future sprints.

Exactly! Better estimates is really developer-speak for less variation.