Two Product Backlogs – One Sprint

Forked Road For the last year, our development team combined work from two different product backlogs into one sprint backlog.

One product backlog contained work in support of mission critical television operations. The other was our first consumer software effort, Ript™.

In taking on a sprint commitment, the team did their best to honor a 55%/45% allocation roughly measured in story points. Our primary revenue stream had the higher allocation and the higher priority. The team was to prevent obstacles in the Ript project from endangering commitment to mission critical television support.

We had good reasons for doing it this way. It worked for a while. Then it didn’t. We’re adapting.

Why we did it

  • With six developers we were too small for two teams. We pair and didn’t want a two person team. Been there. Done that.
  • We wanted contribution from everyone on Ript. Jointly conceived and striving for innovation.
  • We wanted everyone to be familiar with our mission critical applications.

Why it worked

  • Our television support projects fit in a cohesive program, were predictable and reliably estimated.
  • The team felt a strong emotional commitment to Ript.
  • The team has a mature Scrum/XP practice.
  • We let the team manage the allocation while holding them accountable to the commitments they set.

Why it stopped working

  • The television support work transitioned to an unpredictable mix of smaller projects and maintenance.
  • Ript grew into a larger project and strained against the allocation assigned it (effectively 2.5 heads).
  • Ript raised enough interest that it became a higher priority to the company.
  • We foresee an ambitious portfolio of projects coming up from both sides of the business.

How we intend to change

  • Grow to create two four person teams.
  • Each team will focus on one line of work.
  • Run two sprints on sync’d two week cycles.
  • Have a co-located product owner proxy for each team.
  • Share the Scrum Master.
  • Two senior developers (manager and coach) will swap between the two projects daily.
  • The remaining six developers will more slowly rotate among teams at sprint intervals.

We’ll still have to balance maintenance and project work within each sprint backlog but we will avoid drawing work from two product backlogs. That solution fit a particular set of challenges from our business and I don’t regret having done it but now it’s time to adjust.

Change drives more change and I expect our actual practice to adapt in ways we haven’t anticipated.

The thing is, as long as we managers protect the integrity and cohesion of the department, I’m confident the team will be able to respond. We’re committed to the company. We’re committed to each other’s success.

This entry was posted in scrum and tagged , , , , by Ken Judy. Bookmark the permalink.

About Ken Judy

I am an executive manager, software developer, father and husband trying to do more good than harm. I am an agile practitioner. I say this fully aware I say nothing. Sold as a tool to solve problems, agile is more a set of principles that encourage us to confront problems. Broad adoption of the jargon has not resulted in wide embrace of these principles. I strive to create material and human good by respecting co-workers, telling truth to employers, improving my skills, and caring for the people affected by the software I help build.

One thought on “Two Product Backlogs – One Sprint

  1. Pingback: Focus and Variety | Ken H. Judy

Comments are closed.