Agile Estimation Techniques: How Teams Can Ensure Best Foundation For Empiricism?

Once the user stories are ready, the team proceeds with release planning. The release planning requires stories to be estimated and prioritized. Since these two topics are critical and significant, we will first look at agile estimation techniques and then see how they form part of release planning. 

Characteristics of Agile Estimation Techniques

With the traditional planning approach, the duration of a task or activity is the only measure representing the size and complexity of the task and the actual time required to implement the requirement. Agile projects use an approach that separates the user story’s size or complexity from the duration necessary to implement the code for the story. Why is this distinction essential? Because it provides for a more accurate duration estimate by facilitating an objective, parametric approach. For example, traditionally, if we want to build a square room, we may say that it will take seven days to make it. We take cognizance of the room’s dimensions and other similar characteristics, but we club everything and produce a single estimation. 

However, we will first note the dimensions separately with the agile approach. This dimension represents the size of the story and the amount of work to be delivered. Now, we look at our capacity to deliver the workload in each period, say one day or week. This capacity calculation includes taking resource availability, tools availability, and the capacity of tools and machines into account and calculating how much work we can accomplish in the given period. Based on this, we determine the total duration required for complete delivery. Again, the story’s size represents the complexity and efforts, and the team’s velocity indicates the capacity to deliver. Now we may end up with the estimate of 7 days again. Still, the benefit of this approach is better suited to manage the complexity, uncertainty, and risks while estimating and thus helps provide a more accurate estimate.  

User stories can size using two measures; Story Points and Ideal Days. Let us look at each of those in detail. 

Story Point Estimation 

User stories are intangible. They are hard to quantify in size like other tangible items can be. With the agile approach, we use relative sizing to measure the story. Teams assign points to the story by comparing them with other stories and ranking them. The product owner ensures that stories are sufficiently detailed so that the team can have better estimates. The absolute ranking given to a story is not essential, but the relative weightage of other stories matters. For example, a user story with 1 point will be half the size of the user story with 2 points. User story with 4 points will be twice as large as the story with 2 points. Remember, the story point values are not the estimates of the time it will take to complete the story but the overall complexity of developing it.  

The First Story

The question with relative sizing is, how to weigh the first story? For relative sizing, you need a benchmark. There are a couple of ways to start with relative sizing. First, do you have any story which looks similar? Something related to what you must have done in the past? If there is a familiar story, you can start sizing that story. Then compare other stories to the familiar story and size those in comparison. Another way is to start with either the smallest-looking story or a mid-sized one.  

Once you start estimating stories, you can put them into buckets. The concept of T-Shirt sizing comes in handy over here. For example, you may treat the stories with points between 1-3 as Small-sized stories, between 5-13 as medium stories, 13-34 as large, and stories with more than 34 story points as Extra Large stories. Estimating with t-Shirt sizes provides an effective way to start with relative sizing. However, the assumptions and classifications must be explicit and known by the entire team.  

An agile team starts the estimation process using t-shirt sizes by comparing them with other stories and product backlog items. The concept is known as triangulation. First, the story is compared with a couple of other stories to see if the relative sizes are OK. For example, if you think a story should have a size 8, it should be appropriately more extensive than a story sized at 3 points and smaller than a story sized at 8 points. The triangulation process helps improve the estimation of relative sizes. The team does not put any estimates on an ad-hoc basis and applies similar criteria for all stories. 

One of the preferred estimation scales is the Fibonacci Series. This approach is because trying to be overly precise increases complexities in estimation. For example, the difference between a story sized at 2 points and a story sized at 1 point is 100%. But the difference between a story sized at 34 and 35 points is 3%. Since we are doing relative sizing, this precision and complexities are not required or desirable. Using sequence represented by the Fibonacci Series or any variation also helps handle uncertainty in estimating more significant stories. 

Planning Poker 

A prevalent technique for estimation is Planning Poker. Planning poker combines expert opinions, analogies, and disaggregation techniques into one and provides quick but reliable results. Entire development teams participate in the estimation by playing planning poker. First, each member is given a card with a valid estimate size written on the card. For the story to be estimated, the moderator reads the story to team members. Next, the team discusses the story. In case of any queries, the product owner provides the answers and clarifications. Based on these discussions, each team member selects a card representing the story point the member estimates for the story. All the members then show the cards at one go. 

The moderator looks at individual estimates. There might be differences between estimates. Members with small or large estimates are requested to explain why they think the story size is small or large. Based on the explanations and ensuing discussions, the team estimates the story again. Once again, members select the cards.  

With each round, estimates will start getting narrower. Generally, depending on the team’s maturity and experience, after three rounds, a consensus emerges. Once the consensus emerges, teams assign the story points around that size. 

Ideal Days

Another but less adopted techniques of story sizing are in ideal days. Ideal Days represent the time it takes to complete a user story without any distractions or gaps. However, ideal days’ estimation suffers from certain drawbacks compared to story points. Although ideal days are easier to explain outside of the team, especially to people from traditional projects background, easier to estimate in the beginning, and help calculate initial velocity, they decay over time.

For example, story A might be estimated for 10 Ideal Days initially. However, once the team improves or becomes comfortable with the domain, technology, or working with other team members, they might estimate the same story to 8 ideal days. In this sense, the estimates in Ideal Days are prone to decay over time. However, since the size is relative to other stories, it does not suffer from this drawback. Also, velocity calculation does not remain as straightforward or effective with ideal days over time. 

Level of Efforts (LoE)

Level of Efforts represents the extent of activities that are required to support the development of the core product. Efforts required for stakeholder management, documentation, and other such activities are examples of activities that the LoE represents.

Estimating using the relative story point method incorporates calculation of LoE, while you identify the stories for iterations, depending upon the historical analysis. However, LoE is a critical element of the teams to keep in mind while estimating.

Finally

Meaningful estimates are critical for inspection & adaption when teams work with an empirical approach. They serve as a guideline around which teams plan their work. Through inspection at regular intervals, the teams optimize the estimates for future work, thus ensuring transparency about the progress and required efforts. Unlike traditional approaches, with Agile, estimates are not the measure of progress, but instruments of agility & flexibility.

The agile estimation techniques also allow teams to ensure that they are following agile principles outlined in the agile manifesto. These techniques provide teams with a way to ensure sustainable development and enhance simplicity.

Agile estimation techniques rely on team efforts. The teams, which will produce the work out the estimate, take the accountability and ownership of the estimates. The shared efforts also help uncover issues or risks, which an individual might miss if the entire team is not involved. Using techniques like planning poker, you can also avoid underestimations or overestimations.