Product Backlog and Sprint Backlog in Scrum
The Scrum methodology cannot be understood without the Product Backlog and the Sprint Backlog, two of the artifacts with which the Scrum team organizes itself to carry out the work and obtain a good final result.
Part of the success of a Scrum project depends on the design of two good Product Backlog and Sprint Backlog. In this article, we will show you what these documents consist of and the tricks to create them and achieve success.
What is a Backlog?
In the context of agile methodologies, the backlog is, to quote the Scrum Guide, “a pop-up, ordered list of what is needed to improve the product. It is the only source of work performed by the Scrum Team.”
In the Scrum methodology specifically, the Product Backlog and Sprint Backlog serve functions related to those tasks, which are to be executed to deliver a product or service that satisfies customers and markets.
In Scrum, the Product Backlog is the list of pending tasks organized by priority to achieve the final deliverable. The Scrum Team executes these tasks in sprints, cumulative and complementary to previous sprints.
Thanks to this list, the Scrum team has visibility on what needs to be done and the deadlines to achieve it. To do this, the Product Backlog is graphically represented on a dashboard showing the work in progress and its status. This dashboard can be customized with more categories, depending on the needs or way of working of each team.
Elements of Product Backlog
The Product Backlog is made up of several elements that enrich the to-do list: user stories, technical stories, and bugs.
Although they are not included in the Scrum guide, it is common to use user stories as functionalities or tasks to be done in a sprint. As the name says, they must be seen from the user’s point of view; that is, when writing them (and we will remember this in the section ‘How to create a Product Backlog’), we must think about the user’s needs to be covered with the final deliverable: facilitate their daily life, improve their leisure time, etc…
With that goal in mind, the stories are written as requested they have. For example, a task could be: “On each product page of this e-commerce, I need to easily see its different features (colors, models, sizes) to buy the one that best suits my desires”.
Technical stories are technical requirements for the fulfillment of a project. They are not tasks to be done, but requirements for the project to move forward. They have no direct value to the user, although they add value to the solution or product, and the Scrum team must execute them for the user to enjoy the final deliverable.
- Creating the product or service architecture
- Learn how to handle new software to accomplish a sprint task
- Create indexes in the database to make queries go faster
Bugs are errors that are detected during the development of the Scrum project and that must be noted in detail in the Product Backlog.
How to Create a Product Backlog
Because of the importance of this document, it is ideal to create and maintain a Product Backlog that is easy to use and manage by anyone on the Scrum team. Here are some tips on how to achieve this:
- As we said before, simple writing and from the user’s point of view.
- Prioritization and division into affordable tasks. Something basic in the Scrum Product Backlog is to order the tasks according to the need for their realization. This prioritization can vary throughout the sprint, as obligations change.
When working in iterations, the backlog is approached in cycles (sprints) that allow the team to focus on each of them and not see the final task as something difficult to achieve.
- Add only really necessary entries. When including a user story, technical story or bug, always ask yourself if it helps to achieve the final deliverable. With the development of the project, it may also happen that some entries are removed.
- Do not worry about the level of specification of all tasks. You can outline the less urgent ones (which may change when the time comes to execute them) and go deeper into the priority ones. As the former take higher positions, further detail to the team what needs to be done with them.
- Include the technical knowledge that team members gain during the sprints, as well as the technical improvements that are applied to the deliverable in the different phases.
Product Backlog Refinement
Product Backlog refinement is, according to the Scrum Guide 2020, “breaking down and further defining elements into smaller, more precise elements. It is an ongoing activity to add details, such as description, order, and size. Attributes often vary by scope of work.”
Refinement is not an event per se, but an improvement of the Product Backlog as the Scrum team moves forward and discovers details, bugs or issues. Refinement meetings are held whenever the teams feel like it and are able to. It will also be the time to reprioritize tasks if necessary.
The Sprint Backlog is one of the Scrum artifacts and is designed during the Sprint Planning event. It consists of a list of tasks decided by the Scrum Team and is a part of the Product Backlog that is worked on during the sprint. It is used to achieve the increment, i.e., the final goal of each sprint, which is added to the previous ones and has to fit with them. In the Daily Scrum (daily meeting), the team members check whether they are on track to reach this sprint goal.
The Sprint Backlog can be represented in a very visual way with a Scrum board; these can be created with whiteboards, a spreadsheet, or any of the team management tools out there, such as Azure DevOps, Trello, Asana, Monday, or Jira.
Once these virtual boards are created, the sprint tasks are placed in columns or lists to see the evolution of their development. For example, a Scrum dashboard might have three columns of tasks, headed as ‘Pending’, ‘In Progress’, and ‘Completed’.
Thanks to this very visual grid, it is easier to check where the sprint is at and to detect possible risks of not reaching the Sprint Goal.