Agile Zone is brought to you in partnership with:

Dave Bush is a .NET programmer and Certified ScrumMaster who is passionate about managing risk as it relates to developing software. When he is not writing or speaking about topics related to Application Lifecycle Risk Management (ALRM), he is an example to his peers as he develops web sites in the ASP.NET environment using industry best practices. Specific topics Dave can address include: • Project management, with an emphasis on Scrum • Test Driven Development (TDD) • Behavioral Driven Development (BDD) • Unit testing and Integration testing using NUnit, Jasmine and SpecFlow • Web Application testing using Selenium • Continuous Integration • Extreme programming (XP) • Coding best practices • Architecture • Code Reviews Dave has "an insatiable curiosity and is always learning." He has been called "the miracle worker" and "hard to replace" by clients he has worked for recently. Contact Dave via LinkedIn ( to find out more about how he can help your organization reduce software development risk Dave is a DZone MVB and is not an employee of DZone and has posted 55 posts at DZone. You can read more from them at their website. View Full User Profile

Are We There Yet?

  • submit to reddit

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.”

Published at DZone with permission of Dave Bush, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)