Scrum, Story Points, and THE Answers to the Universe

Scrum, Story Points, and THE Answers to the Universe -- Story Points versus Hours -- Cartoon -- October  11, 2010


When you think of estimating and planning techniques in Scrum, what method do you think of first?


“There is an official way Scrum says you *must* do estimating and planning,” you may be thinking.

You’d be incorrect.


Thats OK.

See, there is nothing in Scrum that says you have to use any certain technique for estimating and planning.

My recommendation though:


People will continue arguing about the different techniques for-e-v-e-rrrrrrrrrrrrrrrrrrrrrrrrrrrr.

So what.

If you have something that works today, use it.

If you do not have a clue about how to do estimation and planning, or think:

“Hey we are using Scrum and we do not need to tell the customer when we are going to finish….”

Um… try telling your customer that.  Let me know how that goes, because I can pretty much guarantee that answer will not invoke any confidence in your delivery as a team.

Remember, your customer does not care about story points or gummy bears or peanuts or t-shirt sizes or dart boards or ouiga boards or whatever.

Ask the customer what they really care about.

THE answer to that question may rock your universe.


What kind of estimation and planning techniques are you using today?

What works?

What fails?

Please feel free to discuss these and other answers about this topic in the comments of this thread.



I did something today for YOU.

Instead of estimating and planning on when this next cartoon strip would get to you… I just did it.

THAT is why people are reading this (you are my customer as someone who reads this blog, and I thank you for that!).

PS –> Yeah, I am coming out of a long term slumber from publishing cartoons on this site (for instance, THIS cartoon has been sitting and yelling at me for over a year to GET STARTED again already.  Stop planning on, “The next day…”).  Man, talk about analysis paralysis.  I was there with this site.  For those that are new here, welcome!  For those who have been with me for years, let me say an incredibly humble, “Thank you” for sticking with me.  Help me keep these coming to you — if you have ideas (I still have soooooo many) or want to contribute in any way, please contact me and let’s chat.  There are some changes coming to the site, and I’ll let you in on that news shortly.  All good.

Print Friendly


  1. Susan Mulder says

    we used story points. it was a bit of a mission to get the people to stop thinking about time and to start thinking about the actual work that goes in it, but at least they did not argue and actually did what i asked :) it worked!i don’t agree with a two hour baseline though, but we are getting there.

  2. MP says

    The customer cares’ about getting all functionality /tomorrow/

    Educating the customer to work in an agile way and accept the team estimates and prioritise the backlog with the team is one of the most important roles a scrum master can do.

    We use hours or days. The developers think in that way and when we try story points or an artificial method they generally convert from hours before speaking out loud anyway.

    The customer, internal in our case, is charged for each hour works so that makes sense to them as well.

    Still trying to find a technique for more accurate estimates though…..

    • says

      Keep having the conversations between the team and your customer(s). Scrum really does promote having those tough discussions, and this is one of many that really must happen. Good luck and thank you for the comment.

      – mike

  3. Assaf Stone says

    At long last, the cartoons are finally back!

    I printed and stuck this one on my board for all to see (after I wiped my tears from laughing).


  4. says

    It is always hard to push the idea of estimating specially when all the people about scrum is simply to delivery value. Like many of you said, the customer is also concerned about the time when a project will complete for many reasons; accounting, budgeting, market condition, etc.

    For planning purpose, may be the number of hours against the productivity ratio of the team can also be used. For example, if a team is productive for only 30 hours a week, you can use that as some kind of a basis to determine when you will finish the project considering all the requirements of the customer. I am sure these requirements will eventually whittle down as they see the time line and will begin thinking of the most important requirements from a business perspective.

    My two cents…

Leave a Reply

Your email address will not be published. Required fields are marked *