I Learned Why Agile Teams Like to Estimate In Points And Not Hours

I must admit that the first time I had heard of people estimating units of work in points for iteration planning I was confused. Why use points when we have units of time that we can all relate to? 

Points are used by many agile teams in lieu of hours to cleverly avoid a cycle of forecasting a precise number of hours to complete units of work. There is a tremendous psychological advantage of not planning in hours. Planning in hours brings too much baggage of accountability. The purpose of planning is finding an appropriate amount of work to perform within an iteration.

An iteration can be anything, but usually from a week to six weeks. The sweet spots for iterations, I hear, tend to be in the two to four week period. The purpose of planning is defining the amount of work that could be completed in that iteration. That's it. We're trying to define what we can do and then we're going to do it. 

So, why not use hours? Iterations could be measured in hours. Hours or other units of time seem perfect. That's how work is estimated in the world. Velocity is measured as distance divided by time. What better unit to use for time than time?

That was my thinking before I learned that the reason points are so common is because hours and days are very visible outside of the project team. Iteration planning begins to look a lot like forecasting. After learning what happens when C level managers stumble across iteration plans, we found out how much time it takes to explain that they aren't meant to be accurate forecasts, and then to explain that point again.

Allocating work for an iteration plan is a difficult concept for many people to understand.

Let's define agility as a set of practices that are meant to focus the efforts of stakeholders towards achieving the goals of the project and not participating in wasteful activities, such as unnecessary meetings, forecasting, administrative waste, etc.

Forecasting is expensive. If people are expected to be accountable for their forecasts, the forecasts will be safe. The effort that is spent in forecasting and answering to the forecasting is significant. At one job, every team member was expected to use 10% of their time for forecasting. It's worse for team leaders and project managers.

Forecasting encourages poor performance. The easist way to meet your forecasts is to forecast conservatively, i.e. to sandbag. If forecasting is treated like a big deal and failing to meet one's forecasts is treated more harshly than doing less work, people will sandbag.

What purpose does conventional forecasting serve? Essentially it is a tool for people to plan and track progress. Finance/accounting people like hours because they can convert that into their native language, costs or money. With forecasting they can allocate funds for a project and then the project leaders can be accountable for delivering within budget.

Forecasts are for planning budgets and iteration planning is for scheduling tasks. Two similar activities, but they are also very different. In iteration planning terms like SWAG and ROM are used, some wild ahem guess and rough order of magnitude. Those terms are there to let the planners feel more comfortable with providing input. Non-time units are used to help this even more. 

Why? Because when Jeff over in finance stumbles across an iteration plan his first thought is, "oh I wonder how we're doing and will want to compare the actuals with the forecast". If Jeff sees enough to become concerned, he's going to start calling meetings and asking questions. This will take resources away from the project.

Jeff doesn't know about agility. Jeff doesn't want to learn about it. Jeff knows money and accounting and he knows there will be hell to pay if development overruns their budget.

This meeting will invariably involve a conversation about how iteration planning is not forecasting, it's just designating units of work that will be done within a set unit of time, whereas forecasting is designating units of time that it will take to complete a set unit of work. They are very different, yet easily convertable on paper and prone to getting people very excited and spawning more meetings and more administrative overhead.

This is exactly the type of meeting that will bury an agile project. Instead of working on the project, the team members are answering Jeff's questions because Jeff saw something that looks like a forecast.

I think points are too close to hours and I think that numbers are too easy to confuse with tangible units of time. I don't have a great solution, but at the very least I'd recommend using a nonsensical unit. Glimzarks sound good. Instead of estimating in days, estimate in glimzarks. A glimzark is really 20 minutes. 3 Glimzarks to an hour. Don't worry about the conversions or using them in planning, to the team they can be hours, but only within closed doors. Swear everyone to secrecy to not disclose that a glimzark is a unit of work that can be converted to a unit of time.

Outside of the team, a glimzark is a unit of work. Any number of glimzarks is clearly labeled glimzark to avoid confusing iteration plans with forecasts. The factor of 3 is used to make it not appear easily convertible to hours.

Hopefully this clever trick will keep people like Jeff from assuming that an iteration plan is a good barometer for a project's health.