The product backlog is the ultimate to-do list for a Scrum project––It’s the Scrum response to requirements engineering. Examples of items that can be placed inside the backlog includes but not limited to: features, bugs, and change requests. The product backlog is one of three artifacts in Scrum, the other two being Sprint Backlog and Increment.
The product backlog is mutable. It constantly evolves as more details about the product are discovered. The product backlog is a central topic in Scrum because without it the project cannot commence. However, even though we know the definition of the product backlog how exactly can it be implemented? If you ever watched the HBO television show Silicon Valley, you may have noticed wallboards that are peppered with color-coded sticky notes.
This is one example of a product backlog. However, if you were to search for agile jobs on career sites, then you’ll see employers requesting applicants to have knowledge of software tools like Atlassian’s Jira for managing product backlogs. Can a backlog be physical or virtual? Which ones are considered suitable for your company? Go ahead and grab your favorite drink as in this article I’ll answer these questions in detail.
The Truth about Product Backlogs
A product backlog is one of several potential information radiators in a Scrum project––this term was coined by Alistair Cockburn circa 2000  and denotes any large object which shines information. Some examples of objects that can be used as information radiators are: table-top easel pad, flipchart, magnetic chalk blackboard, dry erase board, pen/paper, dry erase paint, wall sticker, electronic whiteboard, or even a sandwich board sign!
As you can see, there’s quite a list to choose from to represent your canvas. There’s also no rule in Agile that prevents teams for mixing formats. For example, a Scrum Team can use a spreadsheet program like Google Sheets to manage their backlog, but can hand drawn graphs on posters to represent burn down charts. Regardless of which format a team adapt it’s critical that the information radiator is transparent to everyone involved in the project, including stakeholders. Scrum relies on transparency to optimize value and control risk.
The Product Owner is the team member who’s responsible for managing the backlog. They need to not only verify that it’s available to everyone but that it actually gets read. Below are my suggestions for producing quality information radiators:
- Location is King: The information won’t radiate if it’s in an obscure location. Position it in an area that gets noticed. Think billboards.
- Easy to see: Viewing information radiators shouldn’t be like viewing the “Snellen Chart.” Use a large canvas so that viewers can effortlessly view the content.
- Easy to understand: The content should be written in a manner so that both technical and non-technical people can comprehend.
- Constantly evolving: Users of a social media site return because they constantly receive fresh updates. The information radiator should be constantly evolving so that team members will habitually view it.
Physical Backlog vs. Agile Software Tools
Scrum Teams can use a physical or digital format to represent their product backlog. A physical format is one that is low-tech while an agile software tool is considered high-tech. I decided to create a list of the pros and cons of physical backlogs vs. agile software tools to assist Scrum Teams with their decision.
Pros of a Physical Product Backlog
- Easy to start
- One-time cost
- Easy to view at a glance
- Can add drawings to make it more engaging
- Can organize information in many formats
- Everyone in the office can access it at their convenience<
Cons of a Physical Product Backlog
Pros of an Agile Software Tool
- Can be distributed
- Can aggregate team’s historical velocity
- Can be used to manage a portfolio of products
- Bug and issue tracking
- Stores data for easy retrieval
- API that allows Scrum Teams to integrate with other agile software tools
- Add-on repository to extend the functionality of the app
- Technical customer support
Cons of an Agile Software Tool
- Large software can present a steep learning curve
- May be overkill for small collocated projects
- Customization could be complicated
- Cloud based systems errors could make it temporary inaccessible
- Recurring monthly fees
My motto is why limit yourself to just one option? There’s so much variety in this beautiful world. Why can’t Scrum teams at least try to combine two solutions to get the best of both worlds? There’s no rule in Scrum that forbids using a combination of a physical task board with an agile software tool for product backlog management.
For example, the team can meet next to the large whiteboard for the Daily Scrum and use an agile tool like Jira to manage aspects of the backlog. Any update requests for the backlog can get added to the whiteboard so that the Product Owner can decide to accept or reject it. If accepted, the new request gets inputted into Jira and shared with the team. This is just one possible scenario, but there are many creative ways to meshing both formats.
Every team is unique, and I would recommend applying the empirical process control to augment your team’s workflow.
Do you prefer physical product backlogs or agile software tools? Why? Post your comment below. Happy Scrumming!
 Sutherland, Jeff, and Ken Schwaber. Scrum Guide | Scrum Guides. http://www.scrumguides.org/scrum-guide.html#artifact-transparency. The official source of Scrum.============================================================================ Want to learn how to use Python's most popular IDE Pycharm? In the free pdf guide "Getting the Hang of PyCharm" you'll learn all of the amazing features in PyCharm along with how to get started with data science. Subscribe to the Purcell Consult newsletter and get started A.S.A.P.