Estimation is one of the most talked about topics in agile-based software development. Although there is already a lot of content available on estimation, many are still confused about how to do estimates efficiently. The product backlog contains the most valuable information about the project that, once estimated rightly, can play a vital role in the success of the project. Therefore, this blog is meant to clear doubts on why to estimate and then discuss some of the best practices for estimating product backlog efficiently.
This is a common question asked by many who are not familiar with what benefits estimation brings to the table. To discuss it better, let's first quickly clarify our product backlog concepts.
A product backlog is a list of items that the Scrum team has to work on next. The items could be new features, fixing bugs, enhancing existing ones, or working on an entirely new product. The product backlog is created by the product owner, who is also responsible for maintaining it throughout the project. However, not all the items listed in the product backlog are meant to be completed. The team decides which ones to work on based on their role in the product's success. This is where estimation of product backlog comes into action.
Estimation of the product backlog helps the team to evaluate the efforts required to complete the task and its importance in product success. Estimation helps in prioritizing items, finding which items require more effort, and finalizing which ones can be delayed for some time. Therefore, teams must prioritize their product backlog through an estimation session to have a well-arranged, organized, and structured backlog.
Estimation of product backlog brings fruitful outcomes for Scrum teams, but it also requires that they do the estimates accurately. There are many stories of teams that do estimate their product backlogs but fail to do accurate estimates. The result is that they might struggle to deliver timely because they didn't estimate the efforts rightly. To avoid such complications, here are some of the best practices that can help you estimate product backlog efficiently:
The very first misconception with estimation is that teams try to estimate product backlog items based on how much time it will take to complete them, instead of focusing on the efforts required to complete them. Time-based estimation does not guarantee accurate estimates. Let's understand it with the help of an example.
Let's assume that you estimated a task to take 4 days to complete. After 3 days of working, you found a serious complication that now requires more time to fix. However, the higher management is hoping to receive an output after 4 days, so it results in distrust and panic in the team for the unplanned delays. On the other hand, if you estimate based on required efforts, you do have some flexibility in delivery time if some unexpected complications arise. Moreover, when you focus on efforts over time, you are already exploring the potential hurdles, so the estimates are more accurate. Therefore, the first practice to remember is to focus on efforts, not time. The questions should be like "how big this task is", instead of questioning "how much time it requires".
Most Scrum teams that are experienced with the estimation of product backlog tend to use story points to do estimates. Story points give a better view of the required effort by considering the complexity of the work, the uncertainty/risk associated with the work, and the efforts required to complete the work. The item that receives more story points means that it is bigger in size and requires more time and effort to complete.
Moreover, story points offer relative estimation, i.e., the efforts of one item compared with the efforts of another item in the same product backlog. For example, one item of the backlog requires triple the effort compared to the other item. This way, stakeholders can also guess the team's velocity, i.e., the number of story points a team can complete in one iteration.
Scrum teams have many estimation techniques to choose from, such as Planning Poker, Async Poker, Dot Voting, T-Shirt Sizing, Affinity Estimation, and similar others. So, the question is how to pick the right estimation technique.
Different estimation techniques suit different estimation requirements. For example, then there is a need to estimate backlog items without much discussion, then Dot Voting suits well. Similarly, if a small team wants to quickly estimate a large backlog, then Affinity Estimation serves the job rightly.
The best and the most widely used estimation technique is the Planning Poker estimation technique. Planning Poker is a consensus-based relative estimation technique that uses Poker-style cards to assign story points to product backlog items. When the members join the estimation session, they are given poker cards with values of modified Fibonacci sequence (0, 1, 2, 3, 5, 8, 13, and 21). Once the session begins, the product owner narrates the user story (product backlog item) and lets the team discuss to clear doubts. Afterward, every member picks one poker card and then they all show their cards simultaneously. If everyone has picked the same card, then that is declared the size of that product backlog item. If there is a variation, then the team discusses it again and re-estimates. This way, the process continues until all product backlog items are estimated. In short, Planning Poker is a consensus-based and mutually-discussed estimation technique.
No matter what estimation technique you use, it is important that you also review your previous similar stories while estimating the current ones. The previous stories give you a glimpse of what went right and what went wrong and tell you if the story points you assigned last time to a similar story were accurate.
This way, when you are estimating the current product backlog and have previous similar stories in reference, you can assign more accurate story points and have more accurate estimates.
Once you have estimated the product backlog items and have relative sizes of all the items, then you should now re-prioritize the items. The team and the product owner can collectively make some changes in the priorities by moving some items up or down. For example, if one item has got more story points, then it can be shifted a little upward, which implies delaying it for a bit until other items are completed.
For efficient estimating of the product backlog, another recommended practice is to involve only those members who are going to work on the project. Some say that the large the estimation team, the more accurate estimates you get. However, that's not true in most cases.
The team members that are called for the estimation session should be only those that will play some part in the product's success. When there are extra members, they might delay the estimation process by asking ineffective questions. Similarly, if stakeholders are also invited to join the estimation session, then that should also be limited to a few key stakeholders and they should also be restricted from distributing the estimation process.
Some teams tend to spend less time in the estimation session, so they rush to complete the estimates in minimal time. In such situations, newbies or members that need some extra time to understand product backlog items, just follow the recommendations of their seniors. This practice takes away the true essence of estimation and even does not result in accurate estimates. The recommended practice is that the scrum master ensures that everyone's opinion is valued, doubts are cleared, and no environment of biasness exists in the session.
Let's say you have a team that is working remotely from different time zones. So, asking the team members to join a remote video-link estimation session at a specific time will be challenging. Similarly, if you have an on-premises team but the members are busy in other tasks, then again it will be time-consuming to wait for them to begin the estimation session. The best solution for these types of situations is Async Poker.
Async Poker is a modified Asynchronous Planning Poker technique in which the moderator (product owner or scrum master) sends the product backlog items to be estimated to the team members digitally and also provides them the deadline by which they have to send the estimates. The members read and understand the stories at their own pace and send the estimates back before the deadline. After receiving all the estimates, the moderator checks if the estimates provided by members match with each other. If there are some variations in a few product backlog items, then a moderator can call a quick session to discuss and reach a consensus. This way, a remote or distributed team can easily do estimates of product backlog without disturbing the workflow.
Estimation of product backlog items brings a lot of fruitful outcomes to the table. The top one is well-prepared team members that have a clear view of where they are headed and what outcomes are expected from them. However, it is also essential that you do estimates rightly to extract the true essence of estimation. By following the above best practices, you can uplift your estimation efficiency. So, follow the above practices and keep enhancing your estimation process.
