Get certified - Transform your world of work today


Estimation Through a Natural Evolution

How to naturally evolve from the man-hour metric to stories in a sprint

9 May 2016

Much has been said about the term Agile estimation. My aim is not to focus on estimation techniques but rather to talk about why we estimate at all. Estimations let the end user know when the product will be ready for a demo, testing, and feedback. Estimates are developed in order to plan deliveries and project dates.

While reading Mike Cohn's book Succeeding with Agile, an important phrase caught my eye, which at first seemed trivial: "You're not being Agile if your metrics are the same as previously used." This statement describes the essence of the Agile transformation and breaking the established rules or guidelines. Historically, projects were estimated in days or hours per man. That way, stakeholders could point to this model if things failed: "No, you told me that for this functionality, it was going to take the team x man hours or y days per man."

Without diving into specific estimation techniques, we realize that a change in metrics involves breaking the rule of man-hours or man-days. Common sense tells us that no one has the same ability to work or to deliver compelling functionality in x or y-hour days simply because a team member said to do so. Estimation is a natural evolution that occurs during the Agile transformation within the team, as well as in the organization.

The first transformation is to break the man-hours or man-days rules so that we can estimate according to all team members when developing functionality. We avoid generating dependencies; we minimize the famous "bus factor" and foster collaboration among team members through knowledge flow or transfer.

Teach the value of comparing estimated story points to other stories, creating a baseline. For example, the team must identify which story takes five hours to complete and which one takes seven. The baseline story is the one that the team can associate with. From this baseline, all story sizing is compared accordingly. This method is an easy way to estimate. Size the story based on feature difficulty or complexity, and don't consider the time factor. Proceed down the path of natural evolution and toward feature complexity.

After the product owner or client has adapted to this technique, ensure that the team improves their Agile model. Divide the stories proportionately, whereby you set two to three kinds of stories that the team can work with — for example, as relative sizes (S, M, or L) or stories comprising two types: the standard type and two times more complex than the standard type.

This requires a total change in mindset in which the estimation model is adapted to the customer, and the customer has insight into the timing of the product delivery. Agile's true value is in the team's ability to divide the stories and the product owner's prioritization of those stories based on the value of the customer's business.

During this transition, you can be assured by the knowledge of the team that understands both estimation techniques. This especially raises the product owner's confidence, and the customer's, when working on stories that are proportional or equal in complexity.

When it comes to estimation, this is the true Agile evolution. Be Agile because you get to deliver value to the customer, adapt to their needs, and depart from the metrics previously used.

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 (2 ratings)


Tim Baffa, CSM, 5/9/2016 1:29:21 PM

While you did a good job touting the benefits of relative estimation, I do question your statement:

"the team must identify which story takes five hours to complete and which one takes seven. The baseline story is the one that the team can associate with."

If the goal (as it should be) is to wean the team from time-based estimation, then the above approach should be frowned upon. When performing relative estimation, a team should never be asked "how long". Instead, the appropriate question is "how big?".

It is a matter of size, not duration.

A favorite analogy of mine is to think of stories as boulders of rock that need to be moved from point A to point B. The boulders can be different sizes. One or more team members may be "stronger" and can move the boulders quicker than others can, but the "size" of the boulder never changes.

It is always a 50-lb boulder, regardless if it takes the team athlete 2 days to move it, or the scrawny team member 5 days to move it. THAT is the change in estimation that the team needs to understand, and this does not happen "magically" as the team becomes more Agile.
Primitivo Cachero Viejo, CSP,CSM,CSPO, 5/19/2016 7:50:56 AM
I totally agree with you, the problem is you have to change the culture of estimation and depending on the client, team and product owner that change may be faster or slower

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