When I joined my current position, as a freshly appointed scrum master for a young startup, one of the first things I did was setup a Jira account and start listing stories, categorizing them into epics, tracking bugs and setting up forecasts for upcoming sprint using the tools I was familiar with.
I was very proud of my Jira backlog. It was well-ordered, clean and prioritized. Not too long, well kept with epics, custom user flows and sprint forecasts. And it was completely useless.
I'm not going to list everything that was questionable with my way of doing things, let's just say I would approach the situation at a different angle today.
When I was first introduced to scrum, I've worked with a backlog and a sprint board that were managed in Jira, and it worked pretty well. We had multiple distributed teams with members in Paris, New York and Kharkiv (Ukraine). Management and stakeholders were also split on each side of the Atlantic ocean. In this setting, having an online tool to track tasks, bugs and projects made sense, and Jira is the best one I tried. It has a lot of features (sometimes too many), a lot of useful addons (if you were missing the one feature you really wanted) and it globally just works.
Naturally, when faced with a new team suffering from a lack of visibility on projects and delivery, I did what I was comfortable with and put together a Jira backlog.
The reason why it was not such a great idea, is that this new team had completely different constraints. It was a small team of a dozen people, co-located in a single very small office. The team was not interested in using a backlog at all as priorities seemed to shift every two weeks. To them, maintaining a backlog was just wasting time, but I pushed nonetheless.
I held by-weekly grooming sessions with the team, prioritized stories with stakeholders, scoped future sprints... I was once told our investors loved the backlog. The team hated it.
It was time to...
Grab a stack of sticky notes. Find a reasonably flat wall. Write tasks on stickies and stick them to the wall. Congrats, you got a physical backlog!
Then comes the hard part: choosing how to represent tasks and priorities. I suggest involving the whole team in this choice. To help you out, I put together a few examples of the more common ones, in no particular order.
While some will be more effective than others, in the end the right choice is the one that works for you and your team. The only rule is that everyone should understand how the backlog is ordered, the only limit is your imagination.
Once you have made your choice, it works exactly like a tool-assisted backlog. Tasks should be ordered by priority, split into smaller tasks as they reach the 'top' of the backlog. Work should be taken from the 'top' and the state of the board should represent to the best extent the current knowledge of work to be done.
Let's see some pros and cons of using a physical backlog.
All in all, I would seriously recommend talking about it with your team(s), especially if you have issues maintaining or using a virtual backlog. Don't be afraid to jump in, experiment and have fun with it!
I was going to add a FAQ section right about here, but as these were of the top of my head, I decided against it.
Instead, if you have any questions on setting up and maintaining a physical backlog, I would love to answer them in the comments.