Estimation Through a Natural Evolution
How to naturally evolve from the man-hour metric to stories in a sprint
9 May 2016
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.
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.
Current rating: 3 (2 ratings)
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.