Some of the things I read about estimation in the agile community appear to me to be insane. Story points and the reasons that they are the preferable unit of estimate is one of those things. Before you call me a heretic, and burn me at the stake for my blasphemy, and my castigating your dogma – hear me out. I simply don’t find any value in the practice of estimation using story points.
I want to start by stating some facts about software development and estimation.
1) There are no measureable units of output for software development. We have tried source lines of code, and function points, but they really are not a measureable unit of output, they are simply facts about the underlying software product. This is like saying that the number of nails I used (source lines of code) or the number of rooms (function points) is the measurable unit of output for building a house. Both are too variable (rooms vary in size and nails vary by job and practitioner).
2) We estimate using only Units of Input (the denominator) (Since we have no measurable units of ouput), so are estimates are neither repeatable nor generalizable. The input of software practitioners is time. We can choose to represent that time in any way we want, but it is still time.
3) We measure productivity in estimated units of input per actual unit of duration. Since we do not have measurable units of output, we can only measure against estimates.
4) Actual units of input may vary from estimated units of input, but since we have no measurable unit of output, actual units of input are irrelevant to a productivity measure.
5) Cost and duration are forecast based on assumptions around productivity metrics. There are some number W of estimated units of input, and our team’s productivity metric is some number V of estimated units of work(input) per unit of duration, and our bill rate for the team is some number B per unit of duration, so Duration = W/V and Cost = Duration * B – it is really that simple. The magic is in assumptions around V and B and getting the team estimate W so that our assumptions around V become true over time.
Given these truths, it doesn’t much matter what you name your units of input and units of duration, as long as you estimate W in terms of units of input and V in terms of units of input and units of duration.
So from all of you advocates of story points (which appear to vary in size from team to team and from person to person, and from project to project because they are uncorrelated with the actual unit of input (which is time):
How do you project an initial value of V from which to baseline your plan and make your commitment for the initial time box?
Here is my supposition about Story Points:
Story points propose to be an intentionally imprecise metric of software effort. They are uncorrelated to actual units of input. Actual units of input are time. But it doesn’t matter, because we don’t project or predict or forecast or commit based on actuals, we use estimated units of input divided by actual units of duration to do this.
From all the conversations that I have had, the primary purpose of this uncorrelated unit is to prevent or limit the weaponization of metrics. What I mean by this, is the use of metrics in a punitive or manipulative way leading to unsustainable practices: overtime, unexposed technical debt, whip-cycle management, etc. Once metrics are weaponized, they can be used by either the customer, or management but when the weapons are used, there will be destruction.
What else is there?
The alternative to using uncorrelated units of input (story points) is to expose the assumptions behind your projections, predictions, and commitments. Walk your management through how you build your forecast, your schedule, your resource calendar, etc. Explain to your customer what they need to know to make decisions.
While it sounds stupid to tell your customer that your developers only deliver 3-3.5 days of effort per week, it is all that most developers everywhere deliver. There are very sound reasons why it is true. They are the cost of doing business. Collaboration, administration, personal management and learning, team leadership and process improvement all take time away from delivery work, yet all are necessary for a healthy team. Your management knows this and so does your customer, they simply aren’t used to seeing it as an assumption underlying a software delivery projection.
Treat management and customers like “grown-ups” and the trust you earn will be empowering. Don’t give them projections and forecasts without exposing or explaining underlying assumptions, and simply proclaim “You can’t handle the truth” when they ask questions, or misinterpret your intentions.
The value you get out of using correlated units of input is simple. You get the ability to compare productivity across teams using units that have the same underlying basis. You get the ability to compare actual units of input to estimated units of input, understand what the estimate missed, and continuously improve estimating practices. You get a greater level of transparency to management and customer.
No Comments