In its simplest form, a Scrum Product Backlog could be described as a To-Do list for the project. It sets out all the product goals and outcomes that are sought to be achieved and lists out the tasks—based on priority— that the team must perform in order to create the product. A product backlog is agile and dynamic, constantly evolving in tune with the changing requirements of the end-users and the feedback from the stakeholders.
In this article we tell you how to create an effective product backlog, what goes into refining and grooming it, and the pitfalls you must avoid during the process. You will learn the characteristics of good product backlogs and how they keep the team agile.
“The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.” - Scrum Guide
Throughout the duration of the project, the Product Backlog is the one point of reference for product tasks that are listed as per current priority (we say ‘current’, as this list keeps evolving) and is changed to reflect whatever is needed to keep the product useful and competitive in the market.
It is an ordered list of all the features that are needed in the product, along with the use cases, user stories, enhancements and improvements requested after feedback, and bug fixes that need to be carried out.
The Scrum Guide prescribes what can be listed out in the Backlog and ensures that the Product Backlog Items (PBIs) are clearly defined. This includes Features, Functions, Requirements, Enhancements and Fixes.
Each item should be added only after very careful consideration. Check to see whether it adds customer value, is listed according to the priority (the more urgent tasks will come at the top of the list) and is estimated accurately.
Try to avoid adding low-level tasks that are obvious, and will naturally follow from the larger task, as then the list will get very cluttered.
Many teams start out by creating a Product Backlog on an Excel spreadsheet. This works well in initial stages, but as the tasks keep increasing and priorities change, rows will need to be moved and the formatting goes haywire. Especially when this is a shared document, this could prove to be a nightmare.
Software solutions such as Jira or Miro can help to create a living Backlog template that can be easily shared, rearranged and updated. Teams can easily keep track of tasks as they continue to build and iterate, and by putting all ideas and tasks together in one place there is transparency and collaboration across the board.
Once the template that the team will use is decided, the Product Owner will follow these steps to create the Scrum product backlog:
The Product Owner is the SPOC who will be approached by all stakeholders with product ideas. He or she will add these ideas to the list.
Each Product Backlog Item must be clearly understood. Do not add a PBI if you are unsure of the reason behind it, whether it will add value to the product, and what the specifications are.
Items that are urgent can be added at the top of the list, while low priority items will be in the middle. Any items that are ambiguous now but will become clear during the progress of the work, can be added at the very bottom. PBIs that do not offer any value should not be considered at all.
As Agile works on the premise of adapting to changing requirements, these changes must reflect in the Backlog as well. As an ongoing process, the backlog must be constantly updated. Keep re-prioritizing tasks, refining the list, and updating the backlog.
Do keep in mind that the backlog will be referred to by all the members of the team as well. There could be a lot of ideas and suggestions for improvement that are added to the list along the way. While some of them might be let go, there could be others that add great value and will slowly make their way up to the top of the list, getting picked for development in future sprints.
It is the Product Owner’s responsibility to groom and refine the Backlog. During this session, backlog items are reviewed, discussed, and prioritized by the whole team including product owners, product managers, Scrum Master and developers.
The idea of this exercise is to keep the backlog updated and ensure that all tasks that are not completed will be added to the upcoming sprints. During this meeting, product owners revisit the strategic vision behind the product development, and make sure that it is reflected in the Backlog. It is all too easy to lose track of the rationale behind the tasks, and when the Backlog items are refined, the PO will check to see whether the vision is being followed.
Agile backlog refinement is an ongoing task that could be officially scheduled on a regular basis. Product Owners and teams must tidy up the backlog, removing items that are no longer required and moving priorities to the top of the list. While doing so, they will balance stakeholder needs, concerns of the team, and project objectives. They will also consider available resources and project schedules and will optimise the tasks ahead.
During a backlog grooming session, these activities take place:
User stories that are no longer relevant are deleted, and at the same time new ones are added.
Stories that are too large to be handled (called epics) are split into manageable chunks. By splitting epics, the stories that are of a lower priority can be pushed to the next iteration.
As the requirements evolve, some priorities will change and will get re-assessed. User stories that are no longer a priority can get moved down, and the estimates will correspondingly change as well.
By regularly grooming the backlog, product teams will get clarity on the tasks ahead, and can review and complete existing tasks satisfactorily.
In the long term, the product backlog organises the team and helps them to stay on track through the evolution of the product.
The Product Backlog is a critical tool that provides clarity and direction through the development journey. However, to make effective use of it, the Product Owner and team members must have a deep understanding of how to manage it and make the right contributions.
Quite often things do not go as planned, and there are many pitfalls that could happen. We’ve listed out a few of the most common mistakes that should be avoided at all costs:
A Product Owner who is on top of evolving requirements will make sure that they are added to the program's product backlog, making it an outline that is always current and can be relied upon to reflect the new priorities.
It is to be expected that customer needs will change, and stakeholders will challenge priorities, and it is always good to hold discussions to get the list of tasks in line with these changes. The product backlog is also the basis for iteration planning, and it’s important that all work items should be included in the backlog, without leaving anything of importance out of the equation.
As the needs and customer requests change, so will the user stories. As a result, there will be changes in the design, new bugs to be fixed and more technical debt to be handled. The backlog, as a living document, will faithfully record and reflect all these changes.
Scrum expert Roman Pichler has laid out the primary attributes of a good product backlog in his book Agile Product Management with Scrum: Creating Products That Customers Love. Described with the acronym DEEP, this list helps POs stay on track to maintain and efficient and effective backlog.
DEEP stands for Detailed appropriately, Estimated, Emergent, and Prioritized, and is required to be applied throughout the process of backlog refinement.
The details will determine how efficient the progress of work is. As a user story rises up the list of priorities, it should be fleshed out in greater detail. Items that are lower down can be detailed out later, when there is more clarity on the tasks they entail.
All the top priority items should be estimated as accurately as possible to keep schedules and budgets under control. Agile story points that are viewed from the customer’s narrative can be used for more realistic estimation.
As the product unfolds, the team will get more clarity on emergent requirements. The backlog is anything but rigid, and there will be many changes and enhancements along the way. These emergent needs will result in items being added, deleted and refined as the development progresses.
The backlog must always be prioritized. Items at the top represent tasks of a higher priority, and items toward the bottom are of a lower priority. This prioritization is done based on the value each task adds to the product at any given point of time. As the value keeps changing, the priorities will be redefined to match.
A sprint backlog can be a subset of the product backlog. It represents the product backlog items that need to be completed by the Scrum team in that sprint. When the sprint ends, there is a review that is conducted together with the stakeholders, to understand where the product has reached and what needs to be done next. Any items that have yet to be completed will get pushed to the top of the next sprint backlog, or they could also be moved back into the overall product backlog to be taken up during an upcoming sprint.
The product backlog offers a 360-degree, bird’s eye perspective of the overall development project. At any given point of the journey, the current state of the document shows the action items that are currently under way, those that will be done next and those that are at the bottom of the list. Using the backlog effectively, a PO can organise, refine and clearly define the tasks and ensure that there is systematic value addition to the product.