scrum-one-team-multiple-projects

October 25th, 2009

At work we are in the process of implementing Scrum (actually tomorrow is our first Sprint Planning meeting. Really looking forward to it.)

Everybody on the team has read the books on Scrum and we are all very excited to finally be formalizing our processes but we are in disagreement about how best to actually implement Scrum.

The problem is that we are a small team responsible for a set of pretty independent applications. All of these applications are in various states:

“Done” – These apps only see bug fixes and very small feature work. Until the business processes around them change there will be little to no work required to maintain them.
“Maintenance” – Apps that are recently released. As the business adopts them they will require small feature changes and bug fixes.
“Greenfield” – Brand new apps that haven’t yet reached 1.0. Lots of work.

Greenfield apps have more than enough work to fill a sprint. Maintenance and Done apps, not so much. So how do you fit work on projects into a sprint if each app has it’s own backlog but might not have enough work for a full sprint?

I’ve searched for an answer and I’ve found the following sites that address it but nobody seems to be in complete agreement.

We have tentatively agreed that we will have one Product Backlog for all of our projects and a sprint can (and probably will) include work for multiple projects. We will have one person that will manage the Product Backlog and will work with the various Product Owners to make sure they understand how and why the work for their projects is placed in the Product Backlog.

So to all the Scrum people out there, is this a common scenario? Is one Product Backlog for multiple projects seem like a reasonable idea? If not how else can we address our situation?