. .

Estimation of Story Points

old weighing scales

It was such a cool idea. The software development industry failed to deliver reliable estimates of tasks. So why not estimate features, or stories with an arbitrary unit. Story Points had been born.

  1. The basic idea is to create a reference item and then base all estimates as a relation to this reference item. A wonderful approach, because all measurements systems of the world are based on this basic idea. Everything is measured in units that represents a relation to a defined reference.
  2. What we measure is the SIZE of a Story = Functionality. So we pick a Functionality (any) and then we compare this one with the one we want to measure.
  3. We say B is x times as big as B.
  4. DID YOU GET THIS!? …. WE DO NOT…  NOT…  NOT…  NOT COMPARE EFFORT. WE DO NOT ESTIMATE THE EFFORT THAT IS NECESSARY TO BUILD B WITH THE EFFORT THAT IS NECESSARY TO BUILD A.
  5. We estimate the relation between … the distance between … functionality A and B.
  6. The XP Gurus 5 years ago tried to explain this by saying. Functionality B is x-times MORE COMPLEX than Functionality B.
  7. AND then it happend: Developers heard in their minds: To DEVELOP functionality B is x times more complex than functionality B. BUT THIS WAS NOT THE INTENTION.
  8. Now you are back to effort estimation on task level. And you have the same problem again. Again you talk about an effort to build something. But this is not possible as we can not estimate the effort. (Not even Taylor estimated the effort he measured the effort! … -> well this leads to the next thought. You will see later.)

Repetition: We compare the complexity of a functionality B with the reference complexity of functionality A.

(Read more on Friday)

Avatar of Boris Gloger
„Mut“ ist jener Wert von Scrum, mit dem sich Boris Gloger am stärksten identifiziert. Er hat in seinem eigenen Leben keine Angst vor radikalen Entscheidungen und vor dem Glauben an eine Idee. Für kein Geld der Welt würde er sich Regeln unterwerfen, die keinen Sinn machen. Er glaubt an Scrum, weil es nicht nur bessere Produkte, sondern auch eine bessere und menschlichere Arbeitswelt schaffen kann.
  • Orlando

    Nice post. I have a question, it may be silly, but… if distance between functionality A to B is, for example, 5. How can I turn that (5*A) into some other unit that can be helpful to know what can be made in a particular time (for example a sprint)?

  • Stefan Schubert

    Hi Orlando,

    the estimation meeting is for the product owner. The product owner uses the estimation to do a rough release-planning based on the estimation. The estimation is for nothing else but this.

    So the estimation is irrelevant for sprint planning as well. Hide it. In the sprint planning the team decides whether they can do the story (commit on it) based in a detailed analysis of the story, not based on their estimation. If they can not commit, the story is not small enough (even if it was a 1 before) OR it contains so many strategic parts (like research on certain technologies, education, build environment etc.) that have to be solved before the story can be drawn.

    As for the release planning (how much can be done in a month, two or three?): Read: http://en.wikipedia.org/wiki/Law_of_large_numbers
    It doesn’t matter how you estimate. In the end you will have quite a predictable schedule. And predictable means not more or less predictable than a classic project plan, because effort estimates are mostly only precise enough if you invest almost as much time as needed for implementation.

    Stefan

  • Stefan Schubert

    What I forgot to mention is that a functional estimation is so intuitive that you can do the estimation for a whole sprint of two weeks in less than one hour.
    This means it requires less than 2,5% of the overall time of the team, whereas classic estimation (including all the concept work needed to do it) requires at least 10% of the time of a big project normally. And the result is no more precise than a size based estimation. That’s why estimation methods like function points used to be widely-adopted.

    Stefan

  • orlando

    Stephan, really thanks for the answer. With that example I finally get the idea. Thanks again!.

  • http://www.borisgloger.com Boris Gloger

    Hi Stephan, thanks for the really good post. I totally agree, there is not estimation in Sprint Planning 1 any more.

  • Sebs

    Estimate in Planning I:
    We tried this once and failed totally. PO never was late with presenting stuff for the estimation meeting to have it in Planning I again. I guess he inspected and adapted.

    After some sprints we are not discussing this size issue anymore. Some observations.

    1. We lost our reference task. Stuff has size. Everybody knows it somehow (common sense).
    Even team newbies sit by and start putting cards on the table (approx after 4 weeks). More important: the newbie worked on a lot of different things crossover the whole product. Not only the “newbie” area.

    2. We do not discuss this anymore, we simply put cards to the table, syncronize informations and everything is great. Sometimes there is need for more discussion, maybe we estimate only one story, but there is another estimation meeting another day.

    3. The words effort, distance or what ever you call it are not exactly the same in everybody’s head. Put the discussions away sometime. I got the picture that the discussion on WHAT exactly SP (or Hypnotoads as we call it sometimes) really is occurs a lot in trainings, real life teams with a bit of practice are more talking about the contents.

    I disagree a bit with the opinion that the team is not using the estimates for planning I. My team does commit based on velocity of the last sprint +x. Plus X turns out to be the stories they where able to extra achive when all the things where done (like in DOD). They are simply using the data they generate day by day, so why disencourage them?
    Additionally the e-meeting is a reoccuring meeting where everybody is in one place. So it’s a good point to exchange informations (we add stuff to the ticketing system) and everybody walks away and has learned something. Not only the PO.
    We never use ONE meeting for a oneway-street-information-flow

  • Joerg Mueller

    Hi Boris,

    that’s a very interesting series of posts. I really like the idea of defining Story Points like this. It could solve the issue of fear people have to give a low estimate.

    I just see one problem. If you ask somebody how complex software is, he will probably only see one way to imagine this complexity. He will try to imagine the effort he needs to create it. So I did some research on the original definitions of story points to see what they suggest. I was surprised to read the following in Mike Cohns “Agile Estimating and Planning”:

    “There is no set formula for defining the size of a story. Rather, a story-point estimate is an amalgamation of the amount of effort involved in developing the feature, the complexity of developing it, the risk inherent in it, and so on.”

    So Mike Cohn could not help me out, he is using effort.

    What are you telling the people what they should imagine? How to think about complexity of a functionality, if effort is not an option?

  • http://link Merlin96

    Well, This site prepared me for the behavior interview and i was able to ace it without any problem. ,

  • http://link Mr.Carrot95

    Carmela visits Liz La Cerva at the hospital to find that she is restrained in her bed, having apparently attempted suicide. ,