Or yet another point of view on what to do with all those bugs in the backlog…
From time to time we observe a new discussion on whether we should put the bugs into our backlog or not. Opinions are diverse but I see one more aspect of that topic.
The idea behind the backlog is to have all items that we plan to ship for a product as some prioritized list. We leave the backlog in the hands of Product Owner and he decides what comes in and how important that thing is. the backlog forms the vision of what our product will be.
When asking ourselves about putting bugs/issues/tickets into backlog we usually look at it from the development team’s perspective. But lets take a look at what happens before product owner puts anything into the backlog.
We as a team perceive the backlog as the only source of the job to be done, but for Product Owner the backlog is the endpoint of the whole process of gathering ideas, requirements, issues from a lot of different sources. At the beginning of a new product development those sources might be:
- real users needs,
- client ideas and requirements,
- team’s own ideas about the product
As the development goes further bugs arise and at that point they are usually addressed during iterations. When our product is finally released and starts it’s own life then the Product Owner may (should?) use all sets of new sources to fill his backlog items list:
- feedback from the market (by e-mial, phone, through company’s help desk),
- bugs reported through the bug tracker directly or indirectly by users,
- sites that manage new ideas (like UserVoice or GetSatisfaction)
All those sources start producing new items that Product Owner is dealing with every day. They may be:
- relevant to the product vision or not,
- duplicates of other ideas that we already know from other sources,
- a part of some bigger requirement that will later on form a user story
Bugs, especially if we adopt the culture of avoiding them instead of waiting for their arrival, are only a small part of the list that Product Owner should think of when forming his backlog. Also each of the sources that Product Owner deals with have their own life cycles.
Bugs in particular might be:
- confirmed and fixed,
- merged with items from other sources to form stories.
Most companies adopting agile methods usually already use some bug tracking systems and have some flows for dealing with issues that are put in those systems.
When they start working the agile way, the first thought is to start putting user stories into the same bug tracker or convert their bug tacking system into agile management system by mapping user stories to tickets. Other think that now, as they’re becoming “agile”, they should stop using their bug tracker and find some “agile tool”. But after all they start thinking about where to put all those bugs and the only place they find is their new backlog.
I think that either way of thinking comes from the wrong assumptions that bugs can be treated as stories or handled the same way as new features development. Instead of that we should put our Product Owner, a “man of vision”, between the list of bugs (bug tracker) and the backlog.
If the Scrum Master or any other similar role (we’re not talking only about SCRUM) is the wall protecting the team and the process during the iteration, then the Product owner should become a wall protecting the product vision and the backlog. Does it mean that no bug will slip into the backlog? No… some of them will as they need to be addressed individually. But many of them will never reach the backlog in the original form.
I like the idealog concept that Mark Mansour described at:
I think bugs should become at first a part of such list (idealog) next to the items from other sources connecting Product Owner with the real world. And only after becoming a part of such buffer they should pass through the first gate and become backlog items. Going from this point to the rich universe of tools you will start with idealog and the backlog (even if the tools to manage them are your white boards or some Spreadsheets). When it becomes insufficient you will end up with both: bug tracker and some agile management tool, as well as with all other tools that might help you gather the feedback about your product.
They all play a different role when we take a look at the product management part of the process.