When my kids were young, my wife introduced a concept for this question that she got from her family that is so brilliant in its simplicity that I wonder that this isn’t common knowledge with all parents. Something they should tell you during Lamaze class. When the kids asked, “Are we there yet?” Which they did very infrequently, we would answer, “Just a few more units.” If you think about it, it is just about as helpful as any other answer we could have given them, “Just a few more hours.”, “Just a few more miles.”, “Sure, get out of the car.” (While continuing to drive the car down the road.) Or “Does it look like we are there yet?” What does the child want to know? Nothing, they are just expressing their displeasure at still being in the car.
Story Points
Story Points remind me of “Just a few more units.” While “Just a few more units,” had no real meaning, Story Points do have meaning, but they don’t answer the question, “how long until we are done?” Story Points don’t represent time, they represent difficulty. Given two stories, a story with 2 story points should be twice as difficult as a story with 1 story point assuming that everything is as it should be. It does not take into account that the code might have technical debt that we need to deal with prior to actually implementing the story. It doesn’t take into account which programmer is going to do the work. It just says, “This story is this much easier or harder than that story.” How long will it take to complete the story? “Just a few more units.” “But wait!” You say, “How can anyone plan a project if they don’t know how long something is going to take? Well, I have two answers to that question.
How Accurately Do You Estimate?
First, if you look at how well you estimate projects now. How’s that working for you? If you are a programmer, you might say, “Yeah, we hit the estimate every time.” But do you? I would be willing to bet that when you estimated a project, you had in mind that you would do a certain number of things.
- Collect the requirements
- Write a nice user interface
- Write clean backend code
- Have the application tested completely.
What I suspect really happened is that you:
- Collect enough requirements to get going and made up a significant number of the rest.
- Wrote an adequate user interface
- Clean code? No, you were just glad to get it all working.
- Testing? We don’t have time for testing.
So you didn’t meet your estimate, you adjusted you scope so you could meet a target date.
Estimates Are More Accurate Over Time
Now, if you use story points AND you concentrate on a well-established definition of done for each story. The programmers can concentrate on writing quality code, and over time, management will learn how long a story point is on average. No, you’ll never know how long a story point will take for any one story. But you will know that if you look at all of the stories we’ve done so far, a story point equals X amount of time. By doing this we achieve two major milestones. First, we move the decisions about what to do or not do up to the management level. Management will be able to see quickly that if we continue at the rate we are going, we will have a releasable product by such and such a date. Second, the programmers can concentrate on writing good code rather than writing code that is simply adequate for today but ends up slowing them down in the future because they were too busy concentrating on delivering “on time.”