. .

Agile Estimation |Basics

Agile estimation is simple, because efforts are not estimated. Whoever learns from me, how to estimate Stories and Functionalities will quickly notice that I never estimate efforts, because that does not work. It is impossible because there are too many variables.

A training participant told me an anecdote: A hiker meets an old man in the mountains. He asks the old man how much time he needs to reach the cabin. The old man does not answer him, but instead uses  his hiking stick to indicate to the man to  just keep hiking. So the hiker continues  on a little bewildered. From afar the hiker hears the old man call out:  “three hours at that speed.”

This story explains what one must know: the speed of the hiker. Or in our case the velocity of the Team. Speed is a derived length of the distance  divided by the time.  If  I want to estimate the velocity, I need to know the time.

The derived size may not contain temporal dimension, otherwise I would calculate the acceleration of the team. (Speed divided by time is the acceleration) . We must determine that we can indeed express a variable, that can define the size. The idea of the XP Community at the beginning of this decade was to determine the size of the stories: with help from Story Points.

So far so good. I have to measure the Stories, or estimate their dimensions in a unit that has no time frame. When estimating size don’t try to estimate the effort of developing the functionality, that already includes time in the concept of effort (effort is performance multiplied by time.)

That succeeds if you have  a reference: take a story  and simply try to define the “dimensions” of this story, which have nothing to do with the implementation of this story. Then you can use this story as a reference,  give it a value and determine the development of all other stories based on this story. Voilà, with that all the stories have been estimated in their size.

Is that clear? Questions: If you do not want to believe what I explained above, open your Physic’s book and check out what it has to say about how to define size.

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.
  • Jose

    Hi Boris,

    Thanks for the post, but I think it confused me. Mike Cohn posted an entry in his blog in June 21st, 2010 (http://blog.mountaingoatsoftware.com/its-effort-not-complexity) that is opposed to your thesis. For him estimations in story points are about the effort required to develop them. Do you think that as an alternative, effort could be used in estimations?

    Anyway, in your opinion to estimate you just need to define the “dimensions” of the story, but this is when teams have problems! What are these “dimensions”? This should be very well defined and explained, because it’s the heart of the matter, don’t you think?

    • http://borisgloger.com/members/boris-gloger/ Boris Gloger

      Well, I definitely do not agree with Mike. I explained why in my post. Dimension will be defined by the team intuitively. Have a look in the post of today ;)

  • Jose

    The Magic Estimation is really, really great! I loved! But I don’t think it clarifies these questions about estimating effort vs size. I understand that the estimations is done intuitively, but we need to offer some guidance to people. If they ask which dimensions, what should we answer?

  • Jonathan

    Hi Boris, I took a really long time thinking about your post and Mike’s, and at first I completely agreed with your point but later on ended up siding with Mike.

    You say because a mountain has 300 story points and my velocity at climbing a mountain is 300 SP/hr, that I can finish in 1 hour. That is completely correct, until you try to estimate how long it takes for me to perform a surgery that is also 300 story points. It WON’T take me 1 hour, because my velocity at performing a surgery is not 300 SP/hr.

    What that really means is everybody’s velocity at doing different tasks is different, and if you have a team of multiple disciplines, how are you supposed to accurately estimate how long a group of various tasks is going to take? How will you be able to accurately say yes I can climb a mountain AND do surgery and in iteration? You can’t, because everybody does certain things at different velocity, and if you don’t view story points as relative effort but view them as absolute complexity, your velocity will jump all over the place between different iterations. You will not be able to decide how many things to commit in each iteration without having to analyze each story and whether my team has an expert with high velocity at that specific story and do some really complex analysis to decide whether you can commit.

    However, using Mike’s “relative-effort” theory, you can. Each iteration you will have a mostly steady velocity of how much relative effort I can produce per iteration. Then if for my team of climbers, I know my relative effort of climbing mountains is low, because I’m good climbers, but I don’t have a low relative effort of performing surgery. That means I can’t commit to performing a surgery in 1 iteration, but that I can climb 1 or several mountains. Even though the 2 stories may have the same complexity, I know which one I can commit and which one I can’t.