Agile Estimations

What are Agile Estimations?

Attempting to predict the effort required to complete a development task is notoriously difficult. It may seem virtually impossible to make data-driven, reasonably accurate project estimates in most software projects due to the immense number of variables, and downright unknowns.

Here are some of my favorite quotes regarding estimations that were written in the last years:

“It’s hard to make predictions, especially about the future.“ - is attributed to a baseball-playing philosopher, Yogi Berra)

“… never make predictions – especially about the future” - Samuel Goldwyn

Nevertheless, estimating work to be done is all about the future.

Why do we need estimates?

Agile projects can be managed more efficiently by using estimates to break down, plan, and prioritize work. Project management can also benefit from proper work sizing in many ways. 

In the planning of any project, questions will arise. Here are some examples of questions that easily explain why we actually need estimations:

• Portfolio Selection: What projects should we do, based on cost vs. benefit?
• Budgeting: How much will our development work cost?
• Forecasting for Clients & Stakeholders: When will we get it?
• Setting Targets for Scope Control: How long should we give ourselves?
• Story Splitting: Are stories small enough for development?
• Capacity Planning for the Team: How much work will fit in the sprint?
• Scenario Planning for the Team: What approach gives the best cost/benefit ratio?

Based on these, we can progress and discuss why we do need estimates. Here are some valid points to consider as benefits.

• Manage stakeholder expectations (both internal and external clients) - they are in a position to set the tone for future projects by using estimates as an indicator of how long it will take to complete them all.
• Improve prioritization - for example, we can have two tickets with identical business values—but one will take twice as long to complete as the other. By assigning estimates, you’re able to prioritize better.
• Choose the “best value” option - the estimates can help determine the best options; for example choosing the best working machine within the budget.
• Coordinate dependencies - having estimates makes it extremely simple to know and prioritize the work, even if the Product Owner is not present.
• Shared complexity understanding - one team creates complex projects and makes the decisions; under these circumstances, it makes sense for them to unite at the same table, put all the information upfront, discuss and decide. 

What is included in an estimate?

As part of the Definition of Done is a checklist that guides activities such as discussion, estimation, and design that take place prior to the implementation of a solution. With a proper Definition of Done, the team can move forward with developing the User Story by discussing the plans. During the Sprint, they can estimate the number of resources and time required for each task in the User Story and design the product increment effectively so that it qualifies as done.

The Definition Of Done activities may include the following:

• Development
• Reviewing
• Testing
• Deploying
• Documentation writing, etc.

Main agile estimating techniques

1. Story Points

Story Points are a comparative unit of measurement. It exists only in comparison and relation to another value.  Agile teams use them to express estimations of the overall effort that is needed to implement the development user stories. The experience, the skill level or the familiarity with the current task can set apart an estimate from a team member to another.  This effort could be anything related to the complexities, risks, and efforts involved.

When you estimate in story points, it really means you estimate effort and assign a value to each backlog item. Discussions between team members with examples of why they estimated that way can clarify the big picture, and then it will be easier to settle on a specific story point.

Popular scoring scales for story points estimations are:

• Fibonacci 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, ….
• Linear sequence ., 1, 2, 3, 4, 5…; or 3, 6, 9, 12, 15, 18, ….

2. T-Shirt sizes

The T-shirt sizes it's a relative Estimation Technique used by the development team when making a request to evaluate whether they think a story is extra-small, small, medium, large, extra-large, or double extra-large. By expelling the numerical score, the development team is allowed to think in a more dynamic manner about the exertion associated with a story. The sizes can, if necessary, be given numerical values after the estimation is finished.

T-shirt Sizing is one of the Story points sizing techniques to estimate user stories normally used in agile projects. Rather than using a number of planning pokers, here, items are classified into t-shirt sizes: XS, S, M, L, and XL.

The benefits of using t-shirt sizing:

• This is a very informal strategy and can be utilized quickly with a large number of items.
• It is a popular agile relative estimation technique.
• Forcing the estimate into one of a fixed set of sizes allows the process to go quickly.
• It is a good way to introduce terms to relative estimating.
• It is very effective for affinity estimating.

T-shirt sizes can be a great way to become familiar with relative estimating. So, start with them if your development team finds that easier. Additionally, try to put some fundamental numbers on the t-shirts (e.g., Medium=5) and after that steadily shift to using the numbers directly.

3. Time estimation 

Time estimation is just that, an assigned number of hours that the team will spend implementing a specific function or story point. In other words, team capacity is computed by the number of working hours during a sprint.

This is usually a hard-to-use technique because you have to precisely estimate how long it will take to accomplish a certain task and as the complexity and effort of the story grow, it is harder to be predictable.

“The first story is easier to implement than the second one because it has very straightforward requirements. The second story is more complex and risky.”

In an ideal world, if everyone would have the same seniority and knowledge, a time estimation approach would work great, but in practice, we are all different, and the team membership differs a lot.

Also, time estimations carry emotional attachment.  Let's say you estimate a task to take 5 hours but finish it in 10 hours. How would you feel about it? And what would you tell your manager?

The bottom line is that we as humans are pretty bad at absolute estimations. It is easier for us to say a task will take more or less effort compared to another task, especially when we talk about the complexity and/or uncertainty involved.

Man hours are successfully used in the operational zone and/or when we talk about repetitive work. For example, a DevOps engineer should make a new environment for a client from scratch - here we know the effort needed because this task was done many times before, and most of the time the steps are written in the documentation and anyone could pick that task (even a junior team member). Another example would be support tickets or other topics that require repetitive work.

4. RICE

The RICE estimation model stands for:

• Reach: how many people will this impact? (estimate within a defined time period.)
• Impact: how much will this impact each person? (Massive = 3x, High = 2x, Medium = 1x, Low = 0.5x, Minimal = 0.25x.)
• Confidence: how confident are you in your estimates? (High = 100%, Medium = 80%, Low = 50%.)
• Effort: how many “person-months” will this take? (use whole numbers and a minimum of half a month – don’t get into the weeds of estimation.)

RICE = (Reach x Impact x Confidence) / Effort

RICE can help immensely when deciding between hard-to-compare ideas. It forces you to think about why a project idea will have an impact, and to be honest about the effort that’s needed to achieve it. This particular method is used for epics or big initiatives.

5. #noestimates

The #noestimates model is new and here are a few takeaways from it:

• Creates focused, relatively stable, bounded, and largely cross-functional teams.
• Focuses the teams on picking the most valuable work to do.
• Breaks down work into small chunks with clear objectives, usually just a few days.
• Measures how long things take, Kanban-style (e.g. 4.8-5.2 days on average).
• Forecast based on short and long-term delivery cycle data.

There are advanced agile teams that go without estimating, remaining highly reliable and predictive nonetheless.

“#NoEstimates is a hashtag for the topic of exploring alternatives to estimates for making decisions in software development. That is, ways to make decisions with 'No Estimates'.” 

                Woody Zuill, one of the most important #NoEstimates advocate

Agile Estimation Pitfalls

There are a couple of pitfalls one should pay attention to and avoid, as best as possible, when constructing estimations.

• Estimating defects that are part of the iteration

Two types of defects can be part of a sprint that should not be estimated. First, defects should be added to the sprint backlog because of technical debt, field requests, etc. These bugs can be part of the estimation process, and sometimes they are not. Second, defects related to coding and testing activities were found during the sprint. These defects should never be estimated, as they are part of the original estimation and should also be part of the definition of done to solve them directly.

• Estimating just to satisfy a process

The team needs to experience added value from the estimation process. If not, the team should reflect on whether to adjust the estimation process or agree to get rid of it.

• Estimating small stories

Is there a real need to estimate stories that take only one or two hours? The answer is No. Instead, the team can use an agreed time box for these specific stories without the entire estimation process.

• Team does not have a safe zone to estimate - Managers who interfere with team estimations

During an estimation session, the team starts to estimate and finds that there is pushback from the manager during every large estimation. Once this occurs, the team will never feel safe sharing their actual estimation. This will result in smaller time estimates that the manager approves but there will also lead to missing deadlines.

• Taking the “expert” estimate

The process of relative estimation involves the whole development team. They are equal and can share their feedback as part of the estimation process. The problem begins when team members lack the confidence to provide their estimation and therefore conform to the opinion of a vital team member. Each team member should be allowed to contribute to the overall effort and share their honest feedback. Otherwise, team performance and spirit will be affected over time.

• Failing to learn

Agile practices always include the concept of “inspect & adapt”, in which the team reflects on their approach and discusses how it can improve the collaboration. The retrospective meeting is a key aspect that allows the team to take the necessary time to learn from the past.  This is the time to bring up stories that seemed to the team like archetypal examples of a certain point estimate, and which therefore might be useful as reference points in the future. Also, this is the perfect opportunity to discuss stories that were widely overestimated or underestimated.

• Estimation is done only by a selected set of developers

Definitely do not do that! Estimates are done based on complexity and should involve possibly every developer in the team. Every team member who has a say on the definition of done should be a part of the estimation. This helps the team achieve a much-needed balance and create a collaborative environment.

• One day equals one point

The key to estimating is to keep it relative. Due to the fact that teams are afraid to give a precise estimate in many cases, it is used - one day of work is one story point and that is the baseline to start all the estimations. This is the Man Days method.

• Take the average or highest estimation

Estimations meetings should promote conversations about the risks, complexity, and potential unknowns within a story. The result should be a relatively accurate estimate. Avoid simply taking the highest estimate or the average without discussing the different perspectives of each team member.

Conclusions

I am sure that most of you would agree that there is no perfect way to estimate any given project. The probability of you estimating to perfection is extremely small. But that does not mean estimations are not a useful tool. The best thing is to balance everything. How can you achieve that? First choose your best method of estimating, taking into account the scope of the project, its size, and its complexity of it. Then make sure you have accountability and establish some rules that will make communication easy within the group. Lastly, avoid estimation pitfalls as much as possible. 

That being said I will leave you with a recommendation on when to use the main agile estimating techniques:

• T-Shirt Sizing:  Teams who are inexperienced with Agile Estimation, with large backlogs, and at the initial stage of assortment should choose this technique
• Story Points: Teams experienced with Agile Estimation, with the intent to prioritize backlogs and at the final stages of assortment, should choose this technique.
• Time Estimates: Known repetitive work, usually around operational work
• RICE - large projects/initiatives with a lot of uncertainty
• #noestimates - advanced agile teams that go without estimating, remaining highly reliable and  predictive

The article A walkthrough in Agile can also be a great source of information.