Estimates are a great resource for teams and organizations to guess what they can achieve, what are the effort requirements, and when they can achieve. When estimates are done rightly, teams get a proper direction path driven by prioritized tasks. In short, estimates are a valuable practice in the modern era, but do we have to do estimates all the time?
Well, this article is meant to clear your concepts around the estimate. We will highlight the importance of estimates, when not to estimate, Scrum views on estimates, and similar other aspects. So, let's jump right to it!
If we consider estimates in a broader perspective not just confined to software development projects, there are multiple scenarios when doing estimates become important, such as:
In simple words, estimates are a great way to align our mind, priorities, and focus beforehand, instead of doing it once we face a backlash.
One of the major concerns with estimates is that it gives a sense of "commitment". When we estimate, someone is going to be relying on it, which means we have to keep the other fellow up-to-date if the estimate does not proceed as per expectations. In addition, consider that you have conducted multiple estimates for multiple things for different people all at the same time. This implies that you have to set up an effective plan to ensure the fulfillment of estimates. Besides that, you will not be able to do many changes in the estimates, as it's going to impact other dependent processes. Moreover, most of the day gets consumed in planning and ensuring everything works perfectly, so it further makes time management a concern.
Some of the main scenarios where estimates aren't fruitful include:
In short, estimates should be avoided when they are meant to bring time efficiency.
If we closely look at different Scrum Guide versions released over time, we will see that the word "estimate" is mentioned at least nine times in the 2017 guide, but the 2020 guide does not use the word "estimate" anymore. This does not mean that Scrum no longer values estimation, but rather it reflects that Scrum does not provide any specific standard or technique that must be used for doing estimates. Therefore, whether its story points, Planning Poker, focus factor, T-Shirt Sizing, and similar others, none of the estimation techniques are the core part of the Scrum framework.
Scrum just presents some basic concepts around estimates and lets teams have the freedom to pick the estimation technique or other approaches that work best for them. So, if a team is confused about whether they should do estimates or which technique to pick, the best way is to do estimates a couple of times with different techniques and see how it impacts the team productivity. If the results are fruitful, then a team can gradually increase its estimation efficiency and finalize the technique that works best.
It is essential to do estimates for product backlog items because estimation is a key to making product backlog items transparent and doing refinement activities around product backlog. Moreover, such estimations are meant to reflect the "efforts" required not the "time" to complete them. Estimations let teams have a common understanding of the product backlog items, discuss the issues, and prioritize tasks accordingly. However, a product owner is still required to assist in aligning priorities, facilitate the development team to pick the best options, and forecast other elements for the stakeholders or customers.
Since estimation reflects the efforts, not the time, so teams are open to picking whatever estimate technique they like. The common estimation techniques used by most teams include Planning Poker, Async Poker, T-Shirt Sizes, etc.
In the Scrum framework, a product owner is not entitled to make a commitment of delivering a specific feature at a specific date until the development team (who is going to work on it) does the estimate. However, if the Product Owner has an understanding of the feature size/complicity and puts it in a certain order in the product backlog, then he/she can forecast the date. Measurable estimates are encouraged, as they increase stakeholders' visibility on the overall progress.
It may seem a surprise to you that there is no such requirement in Scrum to estimate units of work that are planned in the Sprint backlog. Some Scrum teams are doing estimates to find out the amount of work they can complete, while there are also other teams that utilize empirical evidence of the past Sprints to do the best guess for the current Sprint.
In addition, some teams are even able to set up Sprint backlog without doing any estimates (#NoEstimate approach). On the other hand, you will also find teams that are utilizing the Continuous Delivery / Continuous Deployment approach to limit the work in process and focus on lead time. The continuous delivery/deployment approach lets a team remain transparent and predictable without involving estimates. In short, there are different approaches available for teams other than estimates, so it mostly depends on their preference.
To increase transparency, it is important that the development team do daily Scrum meetings and update the progress. The progress can be in any shape, such as burn-down charts, checklists, numbers, or status on the board. The main goal to update the progress is to encourage more work coordination.
Just to be clear, updating progress via burn-down charts or any other method is just a complementary practice. However, we see many Scrum Masters giving too much priority to their burn-downs and even looking for different ways to become more predictable. But there is no such need to be predictable or use burn-downs to indicate the team's improvement in planning skills.
Estimate or no estimate is a question that can take hours of debating but still remain unresolved. As narrated above, there are many benefits of doing estimates and it even becomes mandatory in many situations. But there are other scenarios too that can proceed without an estimate. Overall, it depends on the team and the organization how they want to proceed.
However, if we consider a general opinion, then doing estimates is much more valuable for the development team. As we discussed at the beginning of this article, the following 5 reasons justify the importance of estimates:
If the team is going to do an estimate, it does not have to proceed with complex estimation techniques because it makes the whole process complicated and time-consuming. A simple estimation approach that can fulfill the above reasons is enough. Scrum also does not emphasize specific estimation techniques. Scrum framework just depicts a set of rules to let us know that adaptation, inspection, and transparency are important for empirical processes.
As narrated above, the estimation technique should be simple and must fulfill the required targets. In this perspective, Planning Poker stands as one of the simplest and highly used estimation techniques. Let's have a quick look at how Planning Poker works.
Planning Poker is an estimation technique based on consensus where the members collaboratively reach the team's estimate by first providing individual estimates. The session starts when the Scrum Master, Product Owner, or any other moderator reads the items to be estimated to the team. The team members are then allowed to ask questions and do discussions to clear their confusion and have a clear understanding of the whole scenario.
Once every member understands the items, they then provide individual estimates. Each member holds some poker-style playing cards which contain the values they can provide as an estimate. Mostly the values are based on modified Fibonacci sequence, i.e., 1, 2, 3, 5, 8, 13, 20, 40, & 100. When every member has decided their estimate, they are allowed to show at once. If all members have given the same or close value, then that's the final team's estimate. However, if there is a major variation, then the members who gave minimum or maximum values are given a chance to justify it. Afterward, the team re-estimates to reach a consensus.
Some of the concerns with Planning Poker are that it requires team members to join the session all at once, understand the items right at the spot, and provide estimates instantly. So, if members are busy with some other activity, they have to delay that in order to participate in the estimation session. Similarly, it is also sometimes challenging for new members to understand and provide estimates in one single sit. Moreover, the COVID-19 pandemic has also shifted the on-premises working culture to remote working.
All the above reasons have made teams change their approach towards Planning Poker, which has led to the foundation of Asynchronous Planning Poker or Async Poker. In Asynchronous Poker, the moderator sends the items to be estimated to all members via email. Afterward, members can read and estimate at their own pace and deliver the estimates before the deadline. After that, the moderator checks if the final team estimate is reached or not. Otherwise, a quick online session is conducted to clear confusion and reach a consensus.
Estimation seems a perfect way to project efforts and align priorities, but it does not assist when there is a need to increase completion probability or enhance time management of complex products. In this type of situation, Scrum recommends using "timebox", as follow:
In short, when there is a need for more time efficiency and completion probability, the time-boxed nature of Sprint should be used at full potential.
Estimate or no estimate is a choice of a team. Scrum does not emphasize any one particular approach or a specific technique a team should practice. However, there are some fruitful outcomes for a team that estimates as narrated above. So, a team who is confused between estimate or no estimate, should test out estimation for a few items and see whether it turns out to be more productive for it.
