Have you also had this uncomfortable feeling that your product or sprint backlog is so different and so less tidy that the examples you read in books or articles? I have had it. For some time I even believed that there are those legendary teams and companies somewhere whose backlog is just like from a book. Fortunately, I no longer believe it. A picture is worth a thousand words, so here's an example of a difference between tidy, theoretical backlog of User Stories and a real-life backlog that we deal with on a daily basis.
Real-life backlog
From my experience, a real-life backlog is always a mixture of at least the following kinds of items:
- Nicely crafted User Stories
- Bugs
- Technical improvements related to testing environment, refactoring, redesign, lib updates, etc.
- Work that is really more like a task but for a good reason it needs to be defined and processed standalone (not as part of any of the User Stories)
I'm sure you may have one or two other kinds of items based on your experience. It is not that we are doing anything wrong, it's just real life. Real life backlog contains some other types of items than a theoretical backlog from a book. Let's ask another question though - is there anything that even a crude, pragmatic, real-life backlog should never contain?
Yes and I have some examples of that. I can say they are examples of pathology in backlog management. There's a phenomenon I witnessed many times where the developers feel a very strong need for having their own card on the team's board. It's as if without a card you appear to be worthless to the team's effort. For this reason, I think, people go and invent many strange types of backlog items, like:
- a training (either attending or preparing for as a speaker)
- helping a new team member get acquainted with development environment and codebase
- preparing a demo session for a customer or a stakeholder
When I see examples of this I always think of adding vacation and restroom visits to the backlog as well. I was really not able to find any explanation of this phenomenon other than the urge to be able to point at something and say "this is what I'm doing, this is what is consuming my time at work". If this is the true reason, then that's sad, because it means people don't feel good enough about helping a new colleague with onboarding until that help is there in the form of a board ticket.
The way I try persuade teams not to add this kinds of items to the backlog is to explain that all of these different things such as trainings, customer demos and the like are really a form of tax that all of the team members pay at different times. We all get distracted from working on the "real" backlog by customer meetings, vacation, civic duties, company-wide meetings... The tax will always be there and these activities will only make our backlog more messy than it needs to be (not to mention adding story points estimates to the "tax activities" and summing them up to get sprint velocity).
Wait, so why don't we treat technical improvements, refactoring or enhancements to test environment a tax? And then simply let's not add these items to the backlog - wouldn't it be event? Well, generally speaking yes, we could do that. If there is a run rate of these things then yes, let's call them a tax and don't put them into the backlog. The thing is, sometimes these activities have a significant size and/or there is a need to visualize them in the backlog to manage stakeholders expectations. So again, in real life, we are going to see them from time to time as standalone items, next to our elegant User Stories.
So, here we are: the real-life backlog is a heterogeneous collection of bugs, stories and very likely some other items. As long as it does not contain the "tax activities" we are absolutely fine - no reason to be troubled or embarrassed about its heterogeneous nature. There's also certain way the backlog gradually gets to that less idealistic (although very real) form: we can't predict many of the non-User Story items upfront. We can't say what bugs will be discovered next month and put them into a sprint that will be the next after the next. The development team will identify refactoring opportunities or other improvements as they go, or at least it is very unlikely that they will put these ideas forward with 2 months notice. This means that most of the time the part of backlog that looks like a mixture of different kinds of items is the current backlog - current Sprint or perhaps the current and next or a sliding window of a number of items, if we don't use Sprints.
Dealing with bugs in product and Sprint backlog
Over the course of years I have found an approach to bugs that I strongly believe is the most successful approach and I always try to employ it with any team and in any product. The approach is to prioritize all bugs to the very top, ahead of everything else. Even though to some people it may seem extreme, it always turned to good for me in the long run.
I've been through rare instances when the volume of bugs was such that together, as a team, we were not able to literally put all them above everything else. On those occasions, we still put a significant amount of bugs at the top and left the rest to deal with in the next Sprint and that way we always gradually, but quickly, went back to a manageable number of bugs. I think a warning message I'd like to put here is that we should not let ourselves get deceived that due to an approaching deadline it is better to move on with the User Stories and leave the bugs unresolved. It is a temptation and sometimes it comes up as a push from some of the stakeholders, but in my opinion it is always an erroneous interpretation of the reality. A product or a feature shipped by the deadline is no good if there is still a pile of known, unresolved defects that will discourage the users or result in a rollout failure.
On the other hand, if you have cosmetic defects that will not damage product's going to production and you know you will not be able to fix them anytime soon, don't leave them for later. Kill them. Close them and say they won't be fixed. Leaving them open is the best way to build an unmanageable pile of bugs.
Summary
I hope you already feel the relief - yes, it is OK to have a backlog that looks like this: