An estimate is our best guess for what can be achieved and by when. There are some situations when estimates are very important:
Coordinate dependencies. It can be very useful to know when the team can proceed working on new design if the key expert is temporarily out of office.
Align priorities. During the day we have a list of things to do. Often we estimate the efforts to sort out our priorities.
Choose the "best value" option. Estimates help us to make a decision when we choose between different options, for instance when I choose the best car for a budget
Forecast the weather. Forecast is a great to be better prepared for the future. Forecasts are often based on the empirical evidence.
Shared understanding. When a married couple in disagreement on the benefits of moving in to the new house, probably they are better to sit down and validate some of the assumptions behind the disagreement.
When Not to Estimate
The biggest problem of an estimate is that there's always someone who will be relying on that. I have to inform the other person all the time, if I see that my estimate is not actual anymore. Estimate is often perceived as a commitment. What to do if I have estimated a dozen of different things for different people at the same time? This means that I have to create an ideal plan to meet the estimates. Any changes to my estimates are not appreciated because it will impact all other plans. At the end of the days I feel overwhelmed with a time-management mess. I spend more time to update the plans than actually doing the work. There are situations when estimates doesn't help:
Predicting results of the complex work. It will end-up with time-management mess
Focusing someone to work better. The human is awful to demonstrate best results under time pressure. This is the reason of why professionals are striving to increase estimate - to make the life easier.
Increase effectiveness of time management. Actually estimates decrease effectiveness because of Parkinson Law [1]
What Does Scrum Says About Estimates
Scrum Guide mentions "estimate" at least nine times! Which means that estimates are still important aspect of the framework. But interestingly,
Scrum doesn't impose to use any estimation technique. Poker planning, story points, focus factor, dirty hours and mandays are not a part of the Scrum Framework. Scrum only establishes some rules of the game around estimates and give the teams a freedom of choice on what estimation technique to use.
Product Backlog Items Should be Estimated
Without estimates Product Backlog is not transparent. Product Owner still needs to align priorities, help the development team to find the "best value" option, forecast the weather for his customers or stakeholders. From the other hand when we estimate PBIs we don't try to predict exact time to complete it. Therefore, the team can choose an estimation technique which fits the need. Many Scrum teams are using t-shirt sizes or relative story points (but Scrum doesn't prescribe to use any of those).
Estimation of new PBIs can be a part of regular product backlog refinement activities. It can help the development team to come to shared understanding of the requirements. Planning poker is another great technique to validate that everybody in the team is on the same page.
The People Who will Perform the Work Make the Final Estimate
In Scrum the person who plays Product Owner role cannot commit to deliver a feature on certain date before letting the development team to estimate it first. But Product Owner can forecast the date if he understands the size of feature and put it to the Product Backlog in certain order. Measurable estimates makes the progress visible to the stakeholders.
Estimate How Much Work Can Be Done in Sprint
You might be surprised, but Scrum doesn't require you to estimate the units of work which are planned and placed in the Sprint Backlog for the Sprint. Many Scrum Teams are still using estimates to figure out how much work they can fit, while other Scrum teams just using their best guess based on the empirical evidence of the previous Sprint(s). Many Scrum teams are able to prepare Sprint Backlog without estimates at all. For instance when the team is able to figure out work items of the same size using #NoEstimate approach. Some other Scrum Team are using Continuous Delivery/Deployment approach with focus on lead time and limiting work in process. This approach helps to be predictable and transparent without any estimates!
Update Estimate During the Sprint
For the Development Team to be transparent between each other it is critical to have Daily Scrum meeting and update the progress. Any form of the progress (numbers, status on the board, checklist, burn-down chart) can help to coordinate the work and dependencies inside the Development Team. Burn-down charts is a complementary practice in Scrum, but many Scrum Masters are still worrying too much about their burn-downs and are looking how to be more predictable. Relax, you won't be predictable, and using burn-down chart as indicator of team improvement in terms of planning is absolute nonsense.
Estimate Or Not to Estimate
This is the question. As I mentioned, there are 5 reasons why estimates are still matters:
Coordinate dependencies
Align priorities
Choose best value option
Forecast the weather
Shared understanding
Often, the simplest possible estimation technique for those five areas are enough to have the things pretty much transparent. Scrum doesn't prescribe or mandate us to use any well known agile or traditional estimation approaches. Scrum framework is just a set of rules to remember us that inspection, adaptation and transparency are critical for empirical process.
Timebox and Priorities Instead of Estimate
What to do in situation when I need to increase probability of completion the complex work? Are there any suggestion to focus the team? How to improve time-management while working on complex products? As it was explained earlier, prediction with estimates doesn't help you to address those challenges, but instead of estimates Scrum suggests us to use timebox:
Sprint is a time-boxed iteration. At the beginning of Sprint the team can set the Sprint Goal and delivers their best results to achieve it within the timebox. This practice can help the team to increase probability of achieving product goals at least every month.
Size of the Sprint Backlog work item is one day or less. I would recommend you to use this Scrum Guide recommendation as a timebox, rather than estimate. It is great to stay focused during the day, having a validated accomplishment at the end. This practice can help the team to see the progress every day. As a time-management practice it can help to find better ways to accomplish complex task, even more effectively while struggling with time.
The length of a Scrum event is timeboxed. This helps to use the team's time more effectively in the meeting.
The good news is that Scrum helps to build appropriate culture of product development, establishing some rules or recommendations for estimates where it is really needed, and rules of timeboxing, as a replacement to the traditional predictive plan-driven approach.
