Product Backlog - Should it be common for both Scrum and Kanban?


#1

Currently, I am coaching a Scrum team and this team is doing really well with agile adoption. The team has about 9 developers. Recently, some new consultants were hired (both onshore and offshore) who will do work from the backlog including some tickets, production support etc. This will be a Kanban team.

Can you share your thoughts/experiences on the following:

  1. Is a common backlog better or a separate backlog better between both Scrum and Kanban teams?

  2. Will Scrum of Scrums work for collaboration between the teams?

  3. What are your top three tips in trying this model with success? Thanks.


#2

Hi

  1. Iā€™ve always believed that ā€œOne product, one product backlogā€ is the best way to go. Having separate backlogs only leads to confusion and is more difficult to track progress. People get confused, not knowing where to raise issues or who is going to work on which piece of work.
  2. Scrum of Scrums is a useful model - go for shorter more regular ones i.e. 2 or 3 times a week lasting 15 minutes each, rather than once a week for an hour. Run it similar to a stand-up, but concentrate on anything that affects other team(s).
  3. Communication, communication, communication :grinning:

#3

I donā€™t know that I have ever heard a compelling reason for a product to not have a unified backlog. Typically, when there are multiple backlogs, you have a lagging indicator of dysfunction in the business operations. It is a statement of multiple top priorities, which is an insight into chaos. Granted, when you have multiple teams and any are Scrum teams, those teams will have Sprint backlogs, but that is different (and mostly fine)

Scrum of scrums is good for tactical and technical blocking and tackling. I also like using product councils or similar for the business side to ensure harmony in the strategy/vision/backlog further out than what is typically covered in a SoS.

I like using the three horizons of planning, leveraging OKRs to fuel backlogs, and making damn sure those that set priority either have the data or the awareness to leverage data when making prioritization decisions. We are well past the ā€œbecause I am the product managerā€ level-of-thinking in this industry. That is no longer an acceptable reason to position an idea on top of another.


#4

@warren,

Thanks for your insight.

On 2. Yes! planning to have SoS two or three times a week where the representatives from each team (preferably on a rotation basis so not the same folks attend each time) will participate in the SoS.

  1. Agree Communication. Since these are two separate teams and each works a little bit differently, we need to balance and remove waste wherever possible.

#5

@ryan, excellent points on unified backlog. I agree and everyone on the team understands the importance of a common backlog. The business side also uses a product council model so we are good there. The product vision with an initial detailed roadmap for the quarter is making a big difference in terms of setting priorities similar to the OKRs fueling the backlog prioritization both from a Sprint Goal point of view for the Scrum Team and objectives for the Kanban Team.

Thanks for your comments.


#6

Great points here! Theres an interesting push right now in the Kanban Community for #NoBacklogs all together as it is viewed as waste (time to fill, groom, etc). In a Kanban System you typically only pull work into the To Do column (which also has a WIP limit) in order to create ā€˜Just In Timeā€™ prioritization and ultimately more flexibility. Food for thought!

Re: Scrum of Scrums- I like to leverage an Enterprise Kanban board (or program level board) for this. You track workflow from discovery to delivery at the Epic level and do stand ups that focus on the work in flight. Iā€™d be happy to share some examples! This level of visibility and communication can really help with cross team/department dependencies too.


#7

@Colleen, thanks for sharing your thoughts here. I agree that there is no backlog in Kanban but we want to operate with the existing Scrum Team so a unified backlog is a great start. We are prioritizing the top 5-10 items for Kanban and pull when ready - just in time. It will be just enough and just in time.

The team is being set up in Version 1 now so still working on the preliminary setup for portfolio items etc. Thanks for your comments.