In Scrum, estimation helps in the proper planning, management, and estimation of the efforts required to implement, test, and deliver the project. Estimation of product backlog items is carried out by the team members going to work on the project to have a shared understanding of the project. However, there is a growing concept that cannot a team begin with the project without estimating product backlog items. So, this article is meant to answer this misconception and discuss in detail the significance of estimation of product backlog items. But let's first quickly clear the concepts around the product backlog and its estimation.
A product backlog is a prioritized list of work including new features, enhancements of existing features, bug fixes, and similar other activities that the Scrum team is going to work next to achieve targeted outcomes.
The product backlog is created by the product owner and includes all the items/tasks that the team is going to work on next. Moreover, the product owner is also responsible for maintaining the product backlog throughout the project, such as re-arranging items, deciding which items to remove, and facilitating backlog refinement. However, it does not mean all the items in a product backlog will be completed by the team. The product backlog just provides the list of tasks to focus on and later the team decides which ones to work on that are deemed important for the product.
Product backlog items can be presented in different formats, but "user stories" is the most common format. User stories are defined as the informal description of the feature of the product from the end-user perspective. It helps the team better understand the backlog items from the end-user viewpoint.
As narrated above, not all items in a product backlog are required to be completed. The team decides the importance of items in the product success during the estimation session. The estimation of the product backlog is carried out by the team that is actually going to work on the product.
The team members join an estimation session where the product owner provides or briefs the user stories and team members estimate the stories using any popular estimation technique, such as Planning Poker, Async Poker, T-Shirt Sizing, Bucket System, or any other technique. Once the estimation of all items is completed, the team has a better mutual understanding of the lined-up work, know which stories are big or small, and can now easily head for sprint planning and start with the first sprint quickly.
There are many articles on the internet debating about the unnecessary need of wasting time in estimating product backlog items. However, they are mostly ignoring the core outcomes that estimation brings for the team. So, below are a few key points that highlight the importance and significance of estimating product backlog items:
The collaborative discussion of product backlog items is not just about understanding the backlog items, but it also helps in projecting the size of the item, i.e., small, medium, or large. If an item size is large, then it means it would take more time or should be divided into small stories. However, when a team picks the backlog item to work on without estimating, you will see the status "In Progress" for months just because the team didn't estimate it thoroughly beforehand.
Product backlog items are mostly formatted in user stories, which means they should contain enough information for the team to understand, estimate, and complete them. When a team estimates a user story and finds out that the information is incomplete, the team can eradicate it from the product backlog until more data is available. However, if a team starts working on the user story without estimation, it would realize it later about the missing details, eventually leading to time wastage and productivity loss.
When a team goes for sprint planning without a prior product backlog estimation session, then it will discover too much about the item during the sprint planning. This might make the members frustrated and tired, and they might eventually commit to the sprint deliverable without having enough understanding of what and how to build. What happens next is again too many discoveries during the sprint that the size of work increases considerably, resulting in loss of commitment and missed deadlines.
As product backlog is the list of tasks that are lined up for the team, so a non-estimated product backlog means the team is not getting a clear picture of what they are going to achieve and when they are going to achieve it. The bigger picture of the project is important to let the members know where their efforts will lead to. Failing to do so results in a less committed team, unproductivity, delayed projects, and similar other complications.
Let's assume you want to create an e-commerce store and sell multiple products. Ideally, the approach will be to go for one or two products first, launch them, learn the market, gain the targeted sales figure, and then head for more products. The goal is to sell multiple products, but the approach is iterative. That's exactly what estimation of product backlog leads the team. When a team estimates the backlog items, they set the mutual understanding of the lined-up tasks and can decide which ones to focus on first. So, the efforts become more oriented to achieve targeted outcomes through the planned iterative approach.
Estimates help the team to have a better guess on when they can complete the project and what outcomes stakeholders should expect from the team. The key stakeholders can even be part of the estimation session to experience the process themselves. Even if stakeholders are not the part of estimation session, they still feel more comfortable working with a team who estimates and show more commitment. Moreover, the team becomes in a better position to negotiate the deadlines with the stakeholders once they know the size of backlog items.
A team comprises members of different skill sets with different responsibilities to fulfill. One pillar of project success is how much team members understand each other and how much they are comfortable working together. Collaboration results in a more committed team that help each other in difficult scenarios. Estimates of product backlog items indirectly make the team members more comfortable with each other. When members spend 1-2 hours discussing, arguing, and estimating backlog items, they are committing themselves to work together in achieving the targeted outcomes.
The summary of the above discussion is that estimation of product backlog items has more beneficial aspects for the team compared to not estimating the backlog items. However, the effectiveness of product backlog estimation also lies in how accurate the team does the estimate. It depends on the estimation technique, the members involved in the estimation, and the commitment of the team to doing accurate estimates. When a team has set shared understanding of the project, the estimates might not be accurate at the beginning, but the consistency of shared understanding will eventually lead to accurate estimates. To sum up, estimation of product backlog items has tons of benefits to offer, so it does not make sense to miss out on this crucial stage that leads to quality deliveries.
