Introduction to the main agile estimating techniques
Introduction to the main agile estimating techniques
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.
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:
Based on these, we can progress and discuss why we do need estimates. Here are some valid points to consider as benefits.
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:
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:
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:
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.
The RICE estimation model stands for:
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.
The #noestimates model is new and here are a few takeaways from it:
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
There are a couple of pitfalls one should pay attention to and avoid, as best as possible, when constructing estimations.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
The article A walkthrough in Agile can also be a great source of information.