The backlog is a well-known scrum artefact. Often people think creating and maintaining the backlog is the most important part of the Product Owner role. Vision comes first, and then the backlog!
What is the backlog?
The backlog is like a wish list. It lists everything you can think you want in order of priority. Those items at the top of the list are well understood and defined and those at the bottom tend to be larger all encompassing items. Backlogs are NOT sets of requirements. Backlogs are NOT inventories of uncompleted work.
The most important part of the backlog is that it contains user stories in priority order. I think all backlogs should start as a whiteboard or post-its. I’ve met too many Product Owners who spend more time with cell formatting and printing size than they spend forming the stories. PLEASE don’t fall into this trap!
Why do we need a backlog?
The backlog exists to maintain a steady flow within the development process. It gives the team a sense of where they are and where they might be going. It is also used to communicate to others the status of their requests.
Keep in mind that backlogs should be groomed often (more on this soon!). The best backlogs are fairly short, it is not a history of all decisions ever taken for the product. It is a wish list of items that you want for the product – now and in the future. As time goes past these wants change and your backlog should be a true representation of this.
Where do I start?
There are many ways to store a backlog. The majority of Product Owners use an excel spreadsheet, but there are many online tools as well.
Step 1 : Your vision.
Step 2 : The best next move is to create a Story Map. This will help in sorting out the order of the bigger activities, and assist in prioritisation. It also aids in communicating the vision for the release to the team, and gives context to individual stories. If you require a release sprint – this is a good place to note that.
Step 3: Once you have broken a few activities down to sub-task level and prioritised and decided on a minimal requirement for the first release, you are ready for the initial backlog. You could also use a treemap to visualise very large backlogs. Think of the backlog as an iceberg, the part you can see (1/7) are the small user stories.
Some backlog tips:
Your backlog should be D.E.E.P (some more info on this)
- detailed appropriately
Here are nine “Rules of Thumb” to keep in mind when working with your backlog.
Some backlog smells:
(signs that something is going wrong)
- you have a fatlog.
- bugs are on the backlog
- you mulch your backlog (this is where a story map comes in handy)
- your backlog has become "archeological."
Links that can help:
Templates for backlogs:
Here are some blogs specifically relating to the Product Owner.