Allan Kelly recently started a discussion on having Three Backlogs in Scrum. The three backlogs he proposes are the ‘Opportunity’, ‘Validated’ and ‘Sprint’ backlog. These allow Scrum teams to keep on top of all requests that come in.
Following Dom Davis’ excellent write up of how it is used at Virgin Wines, I thought I would add my description of how we use the technique at TechHub.
Like Dom, we would describe our process as Scrumban, although we have transitioned most recently from a Scrum background rather than a Kanban one. We work in a very small team at TechHub, but in true Startup fashion, we have a finger in a lot of different pies. At any one time, tasks in our backlog may vary from dealing with support issues through to development and bug fixing. We wanted a way to stay Agile and Lean, but manage to deal with the day to day pressures of support and changing priorities.
Having multiple product backlogs means that we can see all the ideas people have come up with, but focus on those things in the current sprint, what is coming up next. Where we differ from the process Allan describes is that we add a ‘fourth’ backlog between the Opportunity and Validated backlogs.
Our ‘fourth’ backlog, we call the Define backlog. These are things that we think are valuable, but need more investigation before we can really call them validated. In a lot of Scrum processes, the focus is on development and the business - we see a list of what is to be developed and a list of what has been prioritised. As Product Manager, the Define backlog is my backlog - it lets me know which stories I have to be working on so that we can correctly scope and prioritise them.
Whilst I keep an eye on all of the backlogs, and have a good idea where everything is, this allows me to use the scrumban method for my own work. I like to think it keeps me honest - if people are waiting for things in the Define backlog, then they know where to look! Since not all of our stories start out as epics, some will be small, support stories, the fourth backlog is a lightweight way of checking that everything that goes through into a sprint is properly validated.
So, four Product Backlogs. It works for us so far, would be interested to see how other people keep on top of their backlog.
