Using productivity factor effectively to build achievable iteration plans

Folks at Microsoft have great integrity. That is, they do what they say they are going to do and let you know early if they can’t follow through with their commitment. I hope you have the same experience at your company. Maybe we are just lucky at Microsoft to have so may people with this characteristic. However, when I’ve worked on custom application development projects there seems to be a strange “group integrity paradox” where individuals have great integrity but as a group they make commitments that can’t be delivered on. This lack of group integrity is no more obvious than in iteration planning.

Taking a page from any flavor of agile my team uses a productivity factor to build an iteration plan that is achievable based on the historical productivity of the team. What I'm going to outline below is not new to any agile practitioner. However, anyone can benefit from this thinking not mater what your project management style.  

Most project managers will assume some amount of productivity, say 75%. That is fine to build the initial iteration plan. However, we assert that teams must update their iteration plans based on the last iterations productivity. This means after the initial iteration plan is developed some work will get pulled in or pushed out based on real team productivity.

What is productivity?

It’s easy to get snarled in this discussion so from our team perspective we keep it purposely simple. Productivity is how many hours a developer work on tasks and bugs (output) per hour they bill to the project (input).

Consider this next example layering in a few tools we know. A developer bills 40 hours on a project for a week. During that week 30 hours are spent completing work on tasks and bugs from TFS. Why the delta between billed time and time spent on development tasks and fixing bugs? Consider some of my favorite below:

• Last night's build broke. - Lose a day debugging build break, rolling back changes for dev who is not here!
• Today is a bank holiday for Customer team in Ireland. - Lose a day if you have dependencies on that team.
• Customer/EM needs you to justify the time you logged in the time system last week. - Lose 1 hour.
• Project PjM has been pulled into a customer meeting and needs your support in that meeting. – Lose 2 hours (and your mind).
• Sales team needs your expertise to frame to propose engagement extension – Lose 4 hours.
• Customer architect who you work with is a sports fan and wants to talk about last night's game. - Lose 1 hour.
• Project sponsor has asked for a status update on the project. - Lose 1 hour.
• Customer catches you in the hallway and asks you questions for which you need to answer immediately. – Lose 1 hour.

By know you should understand that there is a delta between time spent on the project and time at your keyboard writing code. What does this have to do with iteration planning?

Iteration planning

The starting point for an iteration plan is capacity. Capacity is usually in terms of developer hours. For an iteration consider 10 people, 3 weeks, 40 hours a week we get 1200 developer hours. The most common scenario is to apply an arbitrary productivity factor of 75% and fill this iteration with 900 hours (1200 * .75) of development work. On projects led by my team we assert that the team must use historical productivity instead.

Team productivity is not just specific to the solution. It also is an indirect measure of experience, training, talent and motivation. Also, some environments are less productive than others: technology, environment, morale, team culture all contribute to this.

On most projects we see initial iteration productivity start around 50-60%. Some teams stay at this level others have ramped up to 75%. We do not plan iterations with more than 75% productivity since there will always be meetings to wick away your time working on development tasks.

How to I calculate the productivity of my iteration?

Again, focus on simplicity so you don’t waste time debating a complex formula.

1. For your completed iteration get the start and end dates for the iterations
2. If you are using Team Foundation Server export tasks and bugs assigned to that iteration to Excel
3. Sum completed work for each developer
4. Divide completed work by hours billed in to the project between the start and end dates for your iteration
5. Average the productivity for each developer

Use this number as the starting point to adjust future iterations. Incremental increases to productivity are fine but limit increases to 5% unless there is some change to the project the indicates more productivity. Ideally during your iteration retrospectives the team can identify what management can do to make them more productive. My favorite is have certain days flagged as no meeting days. If implemented the team should commit to increased productivity and the iteration plan should reflect that.

What if you get productivity wrong?

Don’t panic. If the team is more productive than you expect, great(!), pull in work from future iterations. Ideally work is decomposed into capabilities that are portable and have visible dependencies. If the team is less productive don’t adjust too soon as the team may need some time to ramp up. If the team continues to under produce then it may be best to take a page from the agile playbook and revisit priorities with the customer about what can be pushed out to a later iteration. The change here is that in the next iteration you will need to use that lower productivity number so you don’t repeat the same mistake again!

Building iterations based on team productivity is not a license for folks to slack. It’s the starting point to building group integrity and trust with the customer. Early in the project there may be some adjustments to the iteration plan but the team should quickly begin a cycle of delivering what the promised to deliver instead of committing to iteration plans that are known to be a failure from the first day.

One final thought on this. Productivity is an indirect measure of the teams skills and morale. If you put too much emphasis on hitting a “number” then the team can easily game the system if incented to do so. Do this and productivity can’t reliably be used to for iteration planning.