Software firms that use Agile must be familiar with the estimation of product backlog as one of the main planning stages. Product backlog estimation helps the Product Owner, development team, and other key stakeholders get a clear glimpse of the required efforts. However, many Agile teams that practice product backlog estimation often struggle with inaccurate estimates. Mostly it is because they don't perform estimates in the right way and make unintentional mistakes. So, this article is meant to help those teams and provide them with some tips that will help them do accurate estimates of the product backlog. So, let's get started!
A product backlog is a list of prioritized tasks that the development team is going to work next. The tasks can be new features, updating existing features, fixing a bug, and similar others. The top items on the list are those tasks that will be delivered first. Basically, the product backlog is designed by the Product Owner, who derives it from the roadmap or directly from customer feedback. So, the product backlog serves as a central, complete list of tasks for the development team. Once the Product Owner has designed the product backlog, the development team estimates the backlog to know the efforts they have to input. Overall, product backlog makes release/iteration planning easier.
Just like product backlog is an essential element in the Agile framework, its estimation is also vital. Below are some of the main benefits of product backlog estimation:
Overall, product backlog estimation helps the team understand what targeted goals they will accomplish and how much work they can handle. Moreover, it lets the Product Owner re-prioritize the backlog and have a better glimpse of the expected project duration.
Now that we know why product backlog is important and the benefits of product backlog estimation, it's time to discuss how to perform accurate product backlog estimation. So, below are the 8 tips that can help you and your team do accurate estimates of product backlog:
The tune might be professional when the Product Owner creates a product backlog. This might make it difficult for the development team to understand the true purpose of the backlog items. Therefore, it is recommended to turn the backlog items into user stories. A user story is a general, informal description of backlog items that is written from the end-user perspective. The user story helps to understand how the backlog item will deliver value to the user.
The user stories are mostly presented in a single sentence with the format “As [person name/position], I want [requirement], so that [outcome]”. For example, “As a software administrator, I want to access user traffic analytics so that I can propose future software upgrades accordingly. It is not mandatory to follow the single-sentence structure, and the focus should be to present the backlog item from the end-user perspective. Once the backlog items are presented as user stories, the development team can have a better understanding of the expectations and can do estimates more accurately.
You can estimate product backlog items in terms of how many hours it will take to complete them. However, hours-based estimates are not recommended in the software industry due to more chances of unexpected delays or uncertainties that might pop up during the development phase. Therefore, product backlog estimation should be based on story points.
Story points are the units of measurement that reflect how much effort it requires to complete user stories. Teams can use any numeric series to assign "points" to user stories, but the Modified Fibonacci sequence (0, 1, 2, 3, 5, 8, 13, 20, 40, and 100) is a widely used series. Using story points, the team will estimate user stories based on three factors:
Based on these 3 factors, the team estimates how much effort they have to input into accomplishing the goals of a backlog item. This way, they eradicate strict hour-based estimates and get some flexibility in completing the item without stressing much.
Another reason for inaccurate estimates is the stressed-out team due to a lengthy product backlog. It is not necessary for the Product Owner to input all the suggestions and feedback into the backlog. A lengthy product backlog is difficult to prioritize and takes hours to estimate. In such cases, after a few backlog items estimation, the team members might lose their focus and start doing inaccurate estimates.
The best strategy is to keep the product backlog length manageable. The Product Owner can update the product backlog after a few sprints, but doing it in the first place is not recommended. Moreover, the team should not spend more than 2-4 hours in estimating product backlog.
Estimation of the product backlog is not a verbal thing. You need to use the right estimate technique. There are various estimation techniques you can choose from, as follows:
There are many other agile estimation techniques you can use to estimate product backlog. Out of all, Planning Poker is the most widely used technique because it offers the most accurate estimates. So, pick Planning Poker or any other estimation technique that best fits your business model.
Traditionally, the product backlog is estimated on-premises in a meeting room where all the participants join. However, there are occasions when a few participants are busy with other tasks or join the meeting room late. Similarly, if there are a few remote employees, then again, on-premises estimation is a challenge. In such cases, remote-based estimates can serve the purpose rightly. A technique called Async Poker or Asynchronous Planning Poker can serve this job perfectly.
Async Poker is a modified Planning Poker estimation technique meant to assist in remote-based estimates. In this technique, a moderator sends the user stories to participants and gives them a deadline to deliver the estimates. So, participants read and understand user stories at their own pace and send the estimates to the moderator before the deadline. The moderator then gathers the estimates and finalizes the team's estimate. If there are some deviations in estimates, then the moderator arranges a quick online discussion session to reach a consensus. This way, Agile teams can complete product backlog estimation without requiring any on-premises presence. There are even tools like Async Poker - Remote Planning&Estimation that provide a one-stop place to execute Async Poker estimation.
Not every team starts doing accurate estimates from the first day. Almost every team starts with inaccurate estimates, and then they gradually improve their efficiency. However, another key to accurate estimates is to use reference stories.
Reference stories mean previous similar user stories that you have estimated in the past. So, if you are going with a user story estimate and you remember that you have done an estimate of a similar story in the past, then check what story point you gave to that story and how accurate that estimate was. This way, you can learn what mistakes you made that time, so you can avoid them now and have a more accurate estimate.
Another reason behind inaccurate estimates is when team members are forced to complete all backlog items estimate in one sit. Mostly, the length of the product backlog estimation session is around 2-4 hours, but this should include 1-3 breaks in between.
Participants should not be stressed, otherwise they will lose focus and dedication. Moreover, teams can practice time-boxed sessions, such as 5 minutes time-boxed discussion round. Overall, the priority should be to avoid a lengthy product backlog, and the session duration should be brief and involve breaks.
There are many teams that are confused about who should participate in the estimation session. So, they often invite participants that have almost zero contribution in the estimation. Usually, the Product Owner, Scrum Master, development team, and some key stakeholders are the participants. But this can be refined further, such as the development team can be shrunk to only those members who are going to work in the development phase.
By limiting the participants, it results in a more focused group that can quickly discuss and make estimates. If there are extra participants, then it can delay estimates and even compromise the accuracy.
It is important to learn how to do accurate product backlog estimates, as it can lead to better timely completion of projects. A prepared mindset about the required efforts and well-informed possibilities of uncertainties can lead to more focused teams who can handle the ups and downs of a project effectively and deliver high-quality products. The above 8 tips to do accurate product backlog estimation can help a lot in improving the overall estimation process in your organization. So, implement the above tips and experience what fruitful results you get within the next 1-2 product backlog estimations.
