Talking Points: Agile Estimation

Jun Leonardo De Vera

ScrumMaster / Agile Coach of Neon Roots

agile estimation

Following up on our series on Agile Inception Talking Points, the next Memo is about Story Points and Complexity when doing Estimation.

Estimation is one of the more controversial topics in software development, particularly in Scrum/Agile. Some in the community are even advocating not doing estimations anymore because of its inherent inaccuracy.

Keep in mind though that accuracy was never the primary goal in agile estimation. Because it gives the false impression that you know exactly what needs to be done and that you have all the information you need as a developer to anticipate the exact amount of time (in hours or minutes) or effort you need to deliver the required output. But for a dev shop like ours, it’s not an option. The reality is that our clients will want to know what will be delivered, when it will be delivered and how much it will cost. Even with complexity and effort needed and essentially coming up with a reasonable forecast, the underlying consequence is probably still more important. That is for the development team to get a more thorough understanding of the requirements as they break down the user stories. Something that may not be accomplished at the onset of pre-development.

And although this memo primarily addresses the scales we use to estimate – story points and complexity, our goal is to provide a glimpse into how we deal with one of the many factors affecting estimation. We hope it will help shed light and make our clients understand this step towards making a reasonable forecast on releases and cost.

  • the best way to interpret story points is to treat them as scales
  • this story is bigger than this and this story is smaller than that
  • we could actually use T-Shirt sizes such as S-M-L-XL but we use points so we could make a reasonable forecast for how long it could take to deliver the work items
  • we don’t use hours because that is tantamount to saying we know exactly what has to be done and how long it will be done, and whereas in truth, we are making guesses based on fairly loose requirements
  • instead of using a constant increment, we use the Fibonacci series when assigning points to denote the uncertainty when assessing the complexity and effort related to a story
  • so it doesn’t necessarily mean it will take the equivalent of four 2-point stories to deliver an 8-point story
  • when we estimate a story and assign them points (1, 2, 3, 5, 8…), we are also saying that the other story is less complex or more complex than the others

agile estimation

One way to illustrate this is to say you have a grape, a strawberry, an apple, and a pineapple, and then you are asked to rank them by which one is easier to eat or harder to eat.

With a grape, you’ll probably just pick it up and put it in your mouth. With a strawberry, you may need two bites depending on how big it is. With an apple you will probably need to peel the skin and slice it. With a pineapple you will have to peel the skin, remove the eyes, carve and remove it from the center, and then slice it.

It might take me the same time to eat two grapes and a strawberry, but it doesn’t mean I could finish the entire pineapple in the same amount of time I could finish two apples.

What you can sense in the fruit-eating example, though, is that you’re relating the complexity to the effort that will be needed or exerted to accomplish the activity. This is the same with user stories and development. It is obviously also related to the different experiences of the people making the estimate. Furthermore, not all grapes, strawberries, apples, and pineapples are the same. The same is true with user stories. But I can have an idea of how many grapes, strawberries, apples, and pineapples I could eat in a given time. And that’s like planning a commitment in for a sprint

It’s also important to note that there are some who don’t advocate doing estimation because estimates are never considered to be accurate; it could be misconceived as a commitment; or cause a client to falsely believe that the estimates are always true during the duration of an engagement even when new information or changes that are factors to the estimation become available.