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.
- http://blog.xebia.com/2008/08/21/agile-maintenance-one-team-multiple-projects/
- http://www.infoq.com/news/2007/12/multiple-projects-one-agile-team
- http://stackoverflow.com/questions/412525/how-does-scrum-work-when-you-have-multiple-projects
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?
(I work with Ryan) I'm happy with what we're planning to do, if for no other reason than the alternative (multiple product backlogs owned by who? dept. managers who've never done Scrum? yikes!) seems very complicated and scary. I'm happy with simple until someone demonstrates we need something more complex.
You most certainly want to have 1 product backlog for your team. You can have multiple teams per backlog, but not multiple backlogs per team. It would put the burden of prioritizing the work on the team.
However if you are going to have multiple projects on your product backlog, I would suggest you only take 1 greenfield project at a time. One of the great effects of Scrum is able to demo the changes at the end of the sprint. Reserve enough time in your sprint to make demo-able progress on your greenfield project.
As for the rest, pick a direction and trust your retrospectives to steer you into the right direction.
It does not matter how bad you are, if you are getting better.
You have implemented retrospectives right? ;)
I use one Gantt chart for all my projects so I can see all the planning.
Then I set more sprints in the same range of time: the sum of time of all sprints must be on one range of time (one sprint time).
So the sprints share the same time and end in the same time.
For example, if my sprints are one week length, if I have two project my sprints remain one week length but complete only half of the stories.
It is natural that if you have more projects the work will go slowly. With the same plan you can redistribute the work to your developers in order to give a priority on some sprints and optimize the human resources.