When estimating the size of work in Agile software development, story points, which are an abstract, relative measurement, are often used. Mature agile estimators will tell you that story points equal the effort required to complete the work plus a few other factors, such as complexity, risk, and uncertainty.
Sometimes effort is misinterpreted and misused as personalized effort rather than abstract effort. Personalized effort takes into account team composition, experience, and skills. Abstract effort does not. Estimating using personalized effort causes estimates to be inherently tied to the people estimating the work, but what we want is estimates that are independent of the people estimating the work because otherwise the work will need to be re-estimated every time the team’s composition or skills change.
In a recent blog post, Mike Cohn, author of Agile Estimation and Planning, revisited story points to clear up some misconceptions that have arisen in recent years. In that post, Mike used the example of “walking points” to describe estimating effort:
Suppose you and I are to walk to a building. We agree that it will take one walking point to get there. That doesn’t mean one minute, one mile or even one kilometer. We just call it one walking point. We could have called it 2, 5, 10 or a million, but let’s call it 1.
What’s nice about calling this one walking point is that you and I can agree on that estimate, even though you are going to walk there while I hobble over there on crutches. Clearly you can get there much faster than I can; yet using walking points, we can agree to call it one point.
– Mike Cohn in the Mountain Goat Software Blog
The principle is that estimated effort should be abstract and not personalized. Someone caught on to this and asked Mike what should happen to effort if a team becomes better at something over time:
Imagine a team with 3 developers that has the job to generate a website and there are two different user stories that both require a small form with 3 input fields and a submit button. The stories a pretty much the same, except that one of this forms has to be implemented in the beginning of the project, while appears quite some time later.
At the beginning the team is kind of new to the technology used and therefore estimates the user stories with 5 story points. That is fine for the first user story, but while progressing in the project the team learns and becomes better and the effort for implementing a form decreases.
– Rupert in the Mountain Goat Software Blog
Mike responded that the two stories should be the same amount of effort:
If I’m following your example in the question, perfectly then I would say that the estimates of the two (let’s call them identical) stories would be the same.”
– Mike Cohn in the Mountain Goat Software Blog
So what are the consequences of estimating using personalized effort instead of abstract effort?
- Estimates are tied to the team’s composition, experience, tools, and skills at the time of estimation
- A team’s velocity does not reflect the true learning and growth of the team because the personalized effort of doing the same thing over and over again typically decreases with experience and time
Why should you use abstract effort?
- Estimates only require re-estimation when the relative size of the work changes
- Velocity reflects the true growth of the team and allows you to show how a team has improved over time
Of course this all sounds good in theory, but how do you estimate using abstract effort and not personalized effort? When you estimate work, compare it to at least two other recent work items that have already been estimated. However, if you compare the work to older items, the team will be more likely to think the new work is less effort due to them now having more experience and skills than they had when they estimated the older work, so the key is to use recent items when doing relative estimation.
If you want to learn more about estimation in Agile, pick up a copy of Mike Cohn’s Agile Estimation and Planning.
Leave a Reply