One of the most significant changes introduced by Agile software development is the concept of estimating projects by complexity rather than by time. This has led to more accurate predictions of delivery, allows for changes midstream, and does not increase cost. Still the concept is often misunderstood and as a result, underutilized.
For years (or millennia) people have been estimating projects based upon how long they think it will take them to complete. This method is logical but highly inaccurate for a bunch of reasons. The first being that it’s hard to guess how long a big complicated project will take before all the requirements are defined. Secondly, people invariably underestimate how long everything will take. And finally, people simply do not work at the same rate of productivity.
My wife and I do the crossword puzzles in the New York Times. We spend about the same amount of time working on them. She finishes almost all of them and I complete about half. She is much better at crossword puzzles than I am. In fact, it is my biased opinion is that she is better at crossword puzzles than almost anyone I know. This may sound like a digression (or spouse bragging) but bear with me.
In the old world of time-based estimates, my wife would estimate that a week’s worth of New York Times crossword puzzles should take about three hours. I would estimate that same effort at about six hours. That’s a pretty big discrepancy and underscores the problem with estimating effort based on time alone.
But in terms of complexity, my wife and I are in complete agreement – New York Times Crossword puzzles start easy on Monday, get increasingly complicated as the week progresses, and are most difficult on Sunday.
Agile Development Methodology offers us a tool to discuss the relative complexity of projects called story points. The higher the story point score, the more complicated the project. A project with a story point score of 2 is more complicated than a project with a story point scale of 1 – but not necessarily twice as complicated – just more complicated. These are only relative numbers.
So, applying story points to my New York Times crossword puzzle example: It makes sense that the Monday crossword receives a story point score of 1, a Tuesday puzzle gets a 2, and so on until Sunday’s receives a 7. My wife and I are in complete agreement that a week’s worth of crossword puzzles is 28 story points (1+2+3+…+7), even if that effort takes us different lengths of time to complete.
Placing our productivity into those terms, my wife, while completing most of the puzzles, is knocking off about 25 story points a week, and I am hitting about 18 story points. Our team crossword puzzle velocity is 43 (25+18), and over multiple weeks (iterations or sprints in agile terms), we can expect that estimate to become more accurate (as we get better at measuring) and slowly improve (as we get better at crossword puzzles).
Velocity is a specific term in Agile. It is not project specific, but it is team specific. Our velocity would not change if we were doing puzzles from another source – providing their relative complexity was properly estimated. Once our velocity is determined, and the complexity of the puzzles estimated, we can predict the rate we will complete heaps of crossword puzzles with great accuracy.
But changing the team would affect velocity. If my wife wasn’t available for a while and our team had to suffer through a less productive substitute, we would see our velocity fall. We would also likely see our accuracy in predicting our velocity suffer until we had figured everything out again.
Bringing all this back to business: Rather than guessing how long or how expensive a huge project will be in advance, it is better to attack it in stages. First, break the problem into small digestible chunks. Second, score the chunks based on their relative complexity. Third, determine how fast the team can process complexity. And finally calculate the delivery date based on the summed complexities of the entire project and the calculated velocity.
An astute observer might note that estimating with story points is just a more granular form of estimating with time and they would be right. But by measuring the rate of productivity – the velocity – and fine tuning the complexity estimation, the focus moves from what we might get done in the future to what we are doing right now. In the language of compromise, this means that we may have to wait a few iterations to learn the final delivery date and cost, but those answers will be a lot more accurate than they ever would have been under the old system.
Agile methodology refines the clues and helps takes the puzzle out of the project estimating.
In part two of this series, I’ll discuss the problems with incremental story point scores and the solution of which I am a huge fan.
Categories: Agile,Agile Scrum,PSC Way