Get certified - Transform your world of work today


Nuances of Agile Estimation

19 August 2016

Estimation is a key step in any kind of work accomplishment and forecasting, and the IT world is no different. Historically, estimation was mainly carried out by individual experts. As we transition to the Agile way of working, instead of individual estimation, the culture is shifting toward cross-functional, team-based, collective estimation. It starts with size estimation rather than focusing only on effort-based estimation by an individual (mainly the developer).

By estimating, the team realizes a more accurate team velocity, which eventually helps the product owner forecast and plan better to meet an end-user expectation that is aligned with the overall company vision.

To that end, the Agile team carries out story point-based size estimation, whereby a story point is considered a unitless number that denotes the size of an item or an element of a requirement functionality and the user story. This number is picked from the Fibonacci series (1, 2, 3, 5, 8, 13, 21, 34 . . . ) or a modified Fibonacci series (1, 2, 3, 5, 8, 13, 20, 40, 100). Before assigning a story point (a number from the series), consider the following factors when assessing the user story:
  • Complexity of the requirement
  • Uncertainty associated with the story
  • Volume of associated work
  • Knowledge available within the team on that domain
The above factors, together with the relative comparison with another story (e.g., bigger/smaller, more complex to solve, less complex to solve), is also considered before assigning a size (in story points) to a story. For example, boiling water is a simpler activity than baking a cake. Therefore, if you assign 2 story points to the task of boiling water, then baking a cake could be given 5 story points, considering it is more than twice as complex as boiling water.

During the second half of an iteration planning meeting, while detailing the how part of building the incremental value through small tasks, the cross-functional team estimates the story points by collaboratively playing the Planning Poker® game.

Below are some of the typical challenges a team faces during estimation:
  • Teams have difficulty in visualizing the size of an item based on the above factors, without thinking about the effort it might take to implement.
  • There is a tendency to oversize the story because the process seems lightweight and thought is not given to the relative comparison between two stories.
  • Not having T-shirt size like XS, S, M, L, XL, XXL for user stories during the backlog refinement session leads to missing the trigger required to break the story down into smaller functionalities.
  • There can be a tendency to preempt the collective discussion and have each individual story owner assign the story points to their project.
  • Distributed teams, if they use only audio and WebEx, are not able to share their respective story point for an item together at one go, and that leads to bias stemming from other members' input.
  • There is often lack of understanding of the need for story slicing; this leads to a situation in which, if the story is half done in mid-iteration, the whole story then moves to the next iteration and the team's velocity is affected negatively.
These challenges can be managed, as the team slowly matures around the estimation process, by focusing on the following best practices:

Coaching and mentoring from the team lead or a dedicated Agile coach

  • An Agile coach or team lead provides focused a Agile estimation training session, including live examples/simulation-based exercises for teams that are new to this practice.
  • The coach or lead supports the team throughout the estimation practice (part of iteration planning), providing real-time query clarification to ensure that the process does not appear one-sided and that everybody on the team participates actively.
  • On a case-by-case basis, the coach or lead helps the team when they sense the need for reestimation and guides them in resizing the story based on the enhanced clarity or reduced uncertainty during the iteration.
  • While conducting the estimation, the lead or coach encourages distributed teams to use collaboration tools, such as video conferencing, smart boards, and the Planning Poker site.

Iteration planning combined with story size estimation and task estimation, in ideal hours

  • Estimate story size in story points, and estimate related tasks in number of ideal hours. Do not relate story sizing to ideal hours/effort for a simple reason: For the same story, effort may vary across team members.
  • After completing a couple of iterations, have the team calculate the number of hours, say H, they put into implementing a story of size N to derive 1 story point. This equivalence of points to number of hours is not mandatory to know.
  • Have a collective cross-functional team discussion about a story to break that story into smaller vertical slices. To better manage a story, consider the INVEST (independent, negotiable, valuable, estimatable, small, testable) criteria.

Knowing the value estimation brings to the team

  • Story point estimation helps the team move from individual to team-based estimation, which unearths various aspects of a particular story when the members of the entire cross-functional team (developers, testers, analysts, etc.) come together to arrive at a consensus.
  • With each iteration, estimation moves toward accuracy through comparison and retrospection. The team gains a better understanding of its true velocity and improves its velocity trend over its Agile journey.
Thus the Agile team can gradually elevate its Agile maturity where estimation plays a big role. It positively impacts the entire product ownership, whereby the product owner liaises between business stakeholders on one hand and the Agile team on the other to better forecast and plan for production releases. This method of work helps reduce the Cone of Uncertainty by building a solution through collaborative estimation and reflection to refine future estimations.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 3 (3 ratings)


Tim Baffa, CSM, 8/19/2016 11:02:00 AM
Very good article Iffat.

It is a matter of personal preference, but while I see the value in identifying the tasks needed to complete a story, I see the estimation of tasks as wasteful.

We recognize and tout the benefits of relative estimation, and establish a relative story point value for a story. We proceed to identify the tasks for the story. Why then do we need to try and come up with an "ideal hour" time estimation for such tasks, especially when the "effort" might vary from team member to team member? Where is the value in that?

Isn't task time estimation the same as if the team collectively estimated the time effort for an entire story (total all of the task time estimates)? Why do relative estimating then?

In my mind, stick with the story point estimation for a story, identify the tasks needed, and then let the team manage the effort. We should not encourage any practice that attempts to equate story points to time units.
Aaron Price, CSM, 8/19/2016 1:58:49 PM
When you say, "Teams have difficulty in visualizing the size of an item based on the above factors, without thinking about the effort it might take to implement," do you mean without thinking about the effort in terms of hours/time? The whole point of estimating is to estimate effort, so I'm just looking for some clarification here. Thanks!
Tim Baffa, CSM, 8/19/2016 4:44:35 PM

One analogy I like to use for stories is that of a 50-lb boulder. It is smaller than a 100-lb boulder, yet bigger than a 20-lb boulder. We're simply talking size at this point.

Now, say the story is to pick up the 50-lb boulder and move it from point A to point B. Stronger team members may be able to move it quicker and easier than other team members, yet the time it would take any of them to move the boulder (complete the story) does nothing to change the "size" of it. It is still a 50-lb boulder.

Relative estimation is based on size, not on effort. The time it might take to move the boulder never even enters the estimation conversation.
Iffat Maliha, CSM, 8/21/2016 12:06:57 AM
Thanks Tim and Aaron. Yes, the focus should be size estimation and effort will eventually become an after effect. The key is, we should not be much worried about effort (as nicely drawn analogy by Tim), though normally it is seen that size is more or les proportional to effort incurred, but let's not worry about effort part, after couple of iterations, there can be a correlation drawn, but that can be for reference and just to have any idea on team capacity (in ideal hours vs. velocity based on story size in story point).
Ram Kompella, CSP,CSM,CSPO, 9/26/2016 2:36:59 PM

Would this article provide more information? Mike has written various books and articles and he is one of the industry thought leaders for Scrum. Here is his article on story points. I recommend his book on Agile Estimation and Planning if you are looking for more details.
Ram Kompella, CSP,CSM,CSPO, 9/26/2016 3:10:10 PM

Would this article provide more information? Mike has written various books and articles and he is one of the industry thought leaders for Scrum. Here is his article on story points. I recommend his book on Agile Estimation and Planning if you are looking for more details.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up