This article is about the importance of the Product Backlog and its maintenance.
I have been with Premium Minds for almost 2 years. During this period I have been part of teams with different agile methodologies: Scrum, Kanban and Scrumban.
I've had contact with many different backlogs (Scrum Product Backlog and multiple Kanban boards with many columns) not only as a Software Engineer, but also as an Agile Coach.
Over time, I have realized the importance of having a good product backlog, hence the decision to write this post.
First, just to clarify, we use Trello for most of our Kanban/Scrumban projects and JIRA (with Agile) for the Scrum ones.
But it doesn't matter what agile methodology that you use, nor the tool that supports it. Let's see...
As a Software Engineer (and also as an Agile Coach)
With Kanban, I only need to know the upcoming 5 or 10 cards. I don't need to see (everyday) the gigantic backlog that the team has for the upcoming months or even years.
With Scrum, it's more or less the same: we have the current Sprint Backlog and we only need to know the prioritized stories that will appear in the next sprints (2/3 at the most).
As a Product Owner
It's easier to prioritize stories and sets of stories (let's call them epics) if they are organized. This organization can be by project (some teams have multiple projects), by epics or by the stories' types (features, bugs, chores, refactor, [re]design, etc.) No matter how you organize your backlog, it probably will be better than a disorganized one.
So, what should we do with that part of the backlog that is irrelevant for now? The answer is quite simple. Move it to another board.
If you use Trello for Kanban (like we do), it's so easy to move cards and lists between boards that there's no reason to keep all the cards on the same board. Since we only need some lists in our daily meetings we can move the remaining to another board, the Backlog Board. This is already happening with some of our teams.
In case you use JIRA to support your Scrum Methodology, the idea is quite the same. Divide your board in two parts: the Sprint Board and the Backlog Board. The former consists of the current sprint and the next 2/3. The latter is for all the other stories with lower priority or without any priority at all.
The easy part is done, now we only have to organize our Backlog Board. Like I said before, you can group the stories the way you prefer. Here, we present some suggestions for Trello and JIRA boards. But, as I said before, the tools are not relevant.
Focusing on Trello boards first.
Note that no matter what the method is you choose to group them, some lists will probably always be there: a list with stories to categorize or to prioritize, another with maintenance stuff (servers, database, etc) or even one with nice-to-have features.
A good rule for your Backlog Board is this: inside a list, the cards are always sorted by priority. Now, let's approach some options for your boards.
One option consists of grouping the stories by project. For instance, one of our teams maintains and develops 4 different projects. It makes perfect sense to keep stories divided per project, or, if it's the case, per sub-project — in case you need more granularity.
The second option is not to care about the projects; the stories are grouped in sets. These sets consist of stories that are related and — many times — have dependencies among them. Ultimately, you may have to wait for all the stories to be done before you can deploy any of them. This set can represent a new module (from front-end to database), an API or just new concepts.
In this approach the lists' order is very important. The lists with top priority are on the left side of the board and the ones with less priority are on the right side.
Another possible way to organize your backlog consists of type-based lists, i.e., lists for bugs, chores, features, refactors. For example, your development process restricts the number of bugs, features and refactors per release. If you have to deploy two bug fixes, three features and one refactor on the next release, then it will be much easier if they are grouped in this way, right?
At the same time, it's easier to track the number of bugs and to guarantee that the most critical ones enter in the development pipeline ASAP.
These are three approaches used at Premium Minds in our Kanban projects and I think they are really useful for their different purposes.
What about the JIRA boards?
The strategy is quite simple. In addition to the current sprint, create the next sprints — 1 or 2 should be enough — that include the next issues that the team will be working on. As an Agile Coach, I hope these issues include acceptance criteria and all the information your team will need to conclude them. If you already had the next sprints, perfect! These sprints will represent your Sprint Board.
The next step is to create "fake sprints" that, as in Trello boards, represent groups of issues. The "fake sprints" are what we call the Backlog Board. The "fake sprints" are equivalent to the Trello lists that I indicated before. You can follow any of my suggestions or you can choose the criteria or the groups that make more sense for your project. As in Trello lists, it's important that, inside the "fake sprints", features are prioritized. If your "fake sprints" have different priorities among them, you can put the most priority right after the Sprint Board.
Besides the real sprints and the "fake sprints", we still have the Backlog provided by JIRA — ideal for non-categorized issues. JIRA boards also have filters that can represent whatever you want (e.g. open bugs, closed stories, issues without story points, etc) — these are the Quick Filters.
JIRA boards have a feature that Trello boards do not have that I consider very helpful in the backlog management: the possibility to collapse sprints (remember that our fake sprints are semantically equivalent to Trello lists) to end up with only the ones that we need to see.
In my head, these backlog refactor and organization strategies are useful, simple and helpful for everyone: team members, agile coaches and product owners.
Why don't you give it a try and give us some feedback?
