Home » Scrum » Are We There Yet?

Are We There Yet?

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


Other post in Scrum

Related Post

  • How to Estimate Software Projects Like a ProHow to Estimate Software Projects Like a Pro We’ve all been there.  Either at the micro level or at the macro level.  Business wants to know, “How much is this going to cost me?”  And as software developers, we all know the answer […]
  • Technical Debt Is InevitableTechnical Debt Is Inevitable loading... Whoa there Dave.  What are you talking about?  Have you given up the fight? You who have preached the TDD religion.  You who’ve struggled to get organizations to […]
  • You Aren’t Doing Scrum If…You Aren’t Doing Scrum If… I’ve been frustrated lately by the flippant use of the words “Scrum” and “Agile” in our industry.  They’ve officially made it to the point of “buzzwords that mean nothing” that get slapped […]
  • 8 Reasons Johnny Does Not Write Bug Free Code8 Reasons Johnny Does Not Write Bug Free Code There have been a number of things that have occurred over the last week that have prompted this particular post.  And for anyone I work with, this is not an indictment of our work place […]
  • How to Sabotage EstimatesHow to Sabotage Estimates Over the last week, I’ve been helping other programmers estimate the task they’ve been assigned and this has caused me to reflect on how I estimate software.  What works.  What doesn’t.  […]

About Dave Bush

Dave Bush is a Full Stack ASP.NET developer focusing on ASP.NET, C#, Node.js, JavaScript, HTML, CSS, BootStrap, and Angular.JS.Does your team need additional help in any of the above? Contact Dave today.

One Pingback/Trackback