Have you ever been asked for a rough estimate, and then later regretted giving a “rough” estimate because the customer tried to hold you to it?
A familiar story
This week I spoke with an agile coaching colleague of mine, and he relayed a story that rang all too true. The team is working on a major project with a fixed date delivery requirement. The work must be done in six months, and the team already has a well prepared backlog of user stories to work on.
My friend prepared a chart showing projected velocity up until that delivery date, and when he gave it to the customer he qualified it by saying “these are just projections, and they are really based on gut estimates.” He made it clear that the projections were not a guarantee, they just helped the team envision if it was possible to get everything done in time.
Can you imagine how this story ends up? You probably can because I bet you’ve been down this road before (I certainly have).
Rough estimates never stay “rough” very long
Later in the project, the team was starting to catch flack from the customer because their actual velocities did not match the projections from very early in the project. The customer basically said “but you committed to this, I have the chart right here!” My friend the agile coach had to remind them that in agile, the commitments are based on individual iterations, and he had not presented that chart of projected velocities as a commitment.
It reminds me of one of my favorite quotes from Steve McConnell, author of Software Estimation:
A single point estimate is usually a target masquerading as an estimate.
My friend was not trying to give a commitment, or even a target. He was giving a rough estimate, and he communicated that when he gave the estimate.
The problem is, his estimate didn’t match up to the disclaimer he was giving.
Put it in writing
When you give a single point estimate, the customer implicitly understands that to mean you will hit that estimate with 100% certainty, even if you give a verbal disclaimer. When they look back at that estimate later on, they won’t remember your verbal disclaimer or the agile training you gave them.
All the customer will see is a single line showing projected velocity, and then they will compare that to the actual velocity and not understand the discrepancy.
So how do you prevent estimate communication problems?
Here are five quick tips:
- Never show projected velocity (or any estimate) as a single point.
- When showing a projected velocity, give a low and high range, or a 3 point estimate (low, high, most likely). Show the whole range in a chart, so that the customer can visually see that there is a range of possibilities.
- When you track your velocity estimates as the project goes on, plot them against that range, and show that you are within the range of possibilities you set out. (If you’re not truly in that range, then you need to reset expectations or make a course correction).
- Never give only a verbal disclaimer about your estimates. Make sure that the chart or timeline itself represents the uncertainty.
- Understand what is most important to your customer. If the fixed delivery date is most important, then show a range of features or velocities that can be accomplished in that timeframe. If the feature set is most important, then show a range of completion dates for that feature set.
