I think that a lot of organizations and companies shy away from Scrum because it operates on a ‘backlog’. While this term often connotes that you have unfinished work in a negative way, Scrum merely assumes that you will meet the requirements by the end of the sprint. A product backlog does seem like a tough term to use but when you see how it’s created, you may rethink your opinion about Scrum.
Essentially, a product backlog is a prioritized features list that has short sentences describing the functions the product has to possess. The waterfall method usually requires a lengthy requirements document that should act as the bible for the project. The product backlog, on the other hand, could be considered placeholders for what’s been discussed about each user story.
How do you begin creating your Scrum Product backlog?
You start with creating User Stories. During the first stage before the first Sprint, the Product Owner usually puts in the most User stories and prioritizes them to his or her preference. It’s a given fact, however, that anyone can add to the backlog with their own User Stories but the prioritization must be discussed with all the stakeholders.
A typical Scrum backlog comprises the following different types of items:
- Features
- Bugs
- Technical work
- Knowledge acquisition
The Features and Bugs are usually written in the form of User Stories while the Technical Work and knowledge acquisition looks like a requirement document line. You can have technical work and knowledge acquisition as sub-items to features and bugs as long as the prioritization tree is mapped accordingly.
Why are bugs and features almost the same? Most of the time, bugs can simply be features that aren’t implemented yet. Technical Work can mean IT-related tasks that the product owner may not understand but is important for the development. Knowledge Acquisition can be exploratory tasks to find solutions to the issues that keep cropping up.
So how do the stakeholders develop the product backlog?
The first sprint planning meeting is vital for determining the prioritization of all the items. The top items should always go first in the development. The power that the team members have (not the Scrum Master!) is to be able to tell the product owner which can be done in the current sprint. Once the items for the current sprint are in place, they’re moved to the Sprint backlog which technically just expands the Scrum product backlog.
Now, the product owner leaves and it’s up to the team to work together to determine which tasks should be done first. While the first five items or so are of course done first, some items are related to others and can be completed at the same time.
For new Agile teams, it may seem that the work getting done is erratic and some processes may be waiting on others. I think that it’s important that everyone add to the Sprint or Product backlog during the first sprint so that it’s easy to determine the overall pace of the team and to learn lessons.
Since Scrum requires daily meetings (with the team members at least), it’s important that the day’s progress is discussed. Here’ you’ll feel the essence of Scrum which is incremental change. Every day, the backlog gets worn down little by little on a working prototype.
If you’re thinking that the backlog can be used as documentation—then you’re right! Sometimes, it’s an even better requirements document and record of meetings than others simply because so much importance is placed on the discussions.
Here is another template to structure your product backlog:
Discover our trainings in :
English:
- AgilePM Foundation – 2 days
- AgilePM Practitioner – 2 days
- PRINCE2 Agile ® Project Management Practitioner – 3 days
- Certified Scrum Master (CSM) – 2 days
- Certified Scrum Product Owner (CSPO) – 2 days
Français
