Story Points: It’s the Thought that Counts
“Do you have an estimate on how long writing the new software will take?”
To the questioner, it’s a completely reasonable question. New software is required and many other decisions hinge on the timeline and cost.
For the software developer, however, it’s often the equivalent of asking, “when will the world end and how?” We’re sure there is a way to figure that out, but it’s going to take time and effort to dig into the problem before giving an answer.
This then, starts the invariable cycle of frustration. “Well, when will you know how long it will take?” “You’re now asking me to estimate a duration for the estimation of a duration?”
In trying to measure the unknown, the software industry has embraced various approaches over the years, including Lines of Code (LoC) throughput rates, Function Point Analysis (FPA), and the Story Points estimation of the Agile world.
Any method that is based on resulting quantities of code artifacts, in my view, is inherently flawed. We as developers do not strive to solve problems with the most lines of code, nor the most complex algorithms. Our best work results in the fewest lines of code.
That’s one of the reasons I really like the story points concept. Story points are not required to be a specific measure of anything concrete. They reflect how the development team understands the problem to be solved, relative to previous problems solved.
Many developers struggle with this as they first encounter Agile. “But what ARE they? Hours? Days? Functions? WHAT?” It’s very hard to embrace a measurement system of something intangible.
As I’ve struggled myself to explain answer this question, one line of thinking came in handy: What is the real output of software development?
It’s not the “lines of code,” for reasons I noted above.
It’s not measurable in “programs,” “screens,” “reports” or “object classes” or anything else whose boundaries and quantity are completely arbitrary, based on the individual developers involved (and may not reflect good decisions).
What we sell, in this business, is “thought.” Code is simply the final delivery vehicle. It’s the effort to break down the complexity of a problem, a challenge, a requirement, and use the tools available to craft a solution.
We might solve the actual problem while using a whiteboard, or scribbling on a bar napkin, or writing a document, or prototyping, or feeding the ducks. The point is that the,actual keying in of code, compiling, building, etc., is only part of what we do. When we focus our estimating on those activities, of course it’s going to be incomplete. The actual valuable work is what goes on between our ears in getting to that point.
Story points allow for that. Story points allow us to quantify, by relative comparison, the time it takes to solve similar problems. Not just “write code,” but “solve problems.” Problem solving is thought. We can’t predict the exact amount of thought it will take to think through a problem. The best we can do is draw a comparison to similar exercises in the past, which is where velocity comes in to play.
Understandably, this will be a hard perspective to embrace, for both developers and their customers. Our stakeholders, in particular, may reject this explanation as a stall tactic, or a deflection.
Here is one possible path to get them on board. Get a book of mixed puzzles. It might contain Sudoku, crosswords, logic puzzles, story problems, etc. Now ask each stakeholder to estimate how long it would take to complete all the puzzles in the book.
Some might outright reject the request. Some might boldly offer a ballpark estimate, already planning a game of “schedule chicken” should they be held to their word. Some might request more time to analyze the book. How many Sudokus? How many pattern matching? How many that I’ve never seen before? Some may venture to assign ranges to each type of puzzle, based on their own personal experiences.
Most will concede that, even if past timing data was available for each puzzle type, there will still be variability and unpredictable errors, snags and retries. Almost no one would think that, since every Soduku requires 81 digits filled in, an estimate can be based on some per-digit number times 81.
Of course, this doesn’t satisfy those stakeholders who must commit to rigid limits of time and money. It does, however, provide a mechanism to illustrate the variability inherent in software development, and make a compelling case against selling to-be developed software at fixed bid budget and delivery dates.