Everyone loves a good list! This simple yet insanely useful tool plays an important role in keeping professionals on track and helping delivery teams realise the vision of their clients.
In software development, we talk of two main lists which guide the progress of our work from start to finish: the product backlog and the sprint backlog.
Both types of backlogs serve a similar purpose: bringing order and clarity to the work that needs to be done by breaking down a project into its component features and the corresponding actions that need to be taken to make them happen.
We’ll delve briefly into each form of backlog in the next two sections of today’s article, and follow that up with some concrete suggestions on how you can maintain your product and sprint backlogs more efficiently and effectively using a tool like ReQtest.
The product backlog is usually in the hands of your product owner and includes a bird’s-eye view of the project the team is working on.
The product backlog is the team’s single source of requirements and contains a list of user stories that describe the various features that need to developed, ranked according to priority in terms of time, cost and usability. Each story needs to contain enough detail so as to permit the team members to estimate and implement each one during their sprint planning meetings.
It isn’t just user stories that go on the product backlog. Other items which may appear on this list include:
- Bugs – defects in the work that need to be addressed.
- Chores – actions that need to be completed but do not add to the final product being developed.
- Epics – longer, more detailed user stories.
- Prototypes – proof of concepts that help the team make decisions regarding which functionalities to include or not.
The main purpose of the product backlog is to:
- Capture any changes in the list of requirements. These can include adding new features and removing or modifying existing ones.
- Ensure that the team aligns its creative efforts with the business goals that owner of the product wants to achieve.
The product backlog is reviewed and updated by the product owner constantly, however the same list is kept throughout the project and changes are made only to the details of the items it contains.
A sprint backlog is a list of tasks that is compiled by the team and which have to be completed during a sprint.
This list is created anew before every sprint. During the spring planning meeting, team members go through the product backlog and select the user stories to be included in the next sprint and the corresponding actions that need to be taken to implement them.
It is essential that the team balances the number and size of the items it adds to a sprint backlog with the resources it has available at each sprint. Estimating how many resources each task in the sprint backlog will take to finish is an important part of good sprint planning
The sprint backlog was traditionally kept on a separate spreadsheet, but with advanced tracking systems like ReQtest, team members can easily move items from the product backlog onto their sprint backlog and share these changes instantly with the rest of their colleagues.
The sprint backlog is updated at least daily and a new one is created for each sprint. Ideally the sprint backlog is updated as soon as a team member picks a task from the board. A good tool supports distributed stakeholders as well.
Using ReQtest to maintain your backlogs
The most important thing maintaining your backlogs it to ensure that the items on it are well organised and accessible to people who need them. ReQtest is an ideal tool to effortlessly manage your backlogs and ensure that everyone is up-to-date with the latest version of your lists.
With the requirements management module you can easily maintain your backlogs by creating configurable templates which help you control the information related to projects and individual sprints, as well as move items from one list to the other.
Adding new information to your backlog on ReQtest is as easy as adding a new drop-down field and naming it. Using the data stored on your backlog you can select multiple items on the list or pinpoint a particular user story or task you’re looking for with the smart search-and-filter functionality.
Once you’ve selected all the requirements you need, use the bulk edit feature to assign all of them to a particular sprint.
To make this process even simpler, you can assign each requirement you add to your list to the Product Backlog by default and when it is time to plan for the next sprint just update the Sprint field-value for each requirement chosen.
To help you decide which requirements should be included in a sprint, it is important to have a common system for assessing the relative priorities of each item on the backlog. This can be done by creating a separate ‘Priority’ drop-down field and assigning each requirement a priority value. This will enable to quickly pull up the most pressing items on the list and work on those next.
Good practices for backlogs
When creating and maintaining product and sprint backlogs there are a number of good practices to bear in mind that will greatly improve the effectiveness of these agile tools.
1. Have a single and correct copy of the list
The backlog is the ultimate authority on the work that needs to be carried out so it’s important to ensure that you have a centralised and ordered list which everybody can access. Storing the backlog on the cloud and making it accessible through your ReQtest project allows you to see the latest version of the list on any internet-connected device, anytime and anywhere.
2. Refine your backlogs regularly
A backlog is a living and breathing entity that should be considered as a work in progress at all times. It is important that new information learned from the clients and the end-users is reflected in the backlogs and that the list is refined continuously by adding, deleting and updating the items on it.
3. Accessible to all team members
Agile places a high value on collaboration and transparency, thus the backlogs should be available for anyone who will need them. Additionally, any changes that are made to the list should be instantly shared with the team so as to avoid any conflicting updates from arising by having multiple people modifying multiple lists.