Geeks With Blogs

Geekus Con Livus Malcolm Anderson's home for Geeks With Lives

Recently a question came up on the ScrumDevelopment list asking about using Scrum an a team doing multiple projects in parallel.  Since being involved on a team doing just that, I've been wanting to take the time to document our approach but have never taken the time to do it.  Now I have an excuse and I thought i would share it with everyone.

> I wonder how would you approach to planning and tracking when there is
> a small (<15) team involved in several projects at the same time (not
> necessary maintaining few product flavours, but still working on one
> product). Usually a project could be completed by few (2-3) developers
> within a dozen iterations.

We did this in our department of a large federal agency.

We had had a team of 6 or 7 developers, working on 5 - 9 projects per sprint.

We had one daily scrum meeting, and a common project board covered in index cards, one story per card, one row per project.  When stories got completed, they were moved over to a corresponding "done" board in our common war room, which also functioned as our meeting room.

We were using 2.5 hours per developer per day as an ideal day, and our pool of "hour points" was distributed to our various customers by our manager.

We aggregated all of the "hour points" into a single burn down chart, but had separate demos and planning meetings for each project.

We worked on 3 week sprints with a 1 week "demo and planing" week between them, which also worked as a opportunity to get things done with infrastructure that no one wanted to pay for.

It's not textbook, but it worked pretty well, and our customers were overjoyed to be getting visible progress each and every month.  Our customers also got to see what other projects we were working on at any given time.

Lastly we used a customer report card to gauge customer satisfaction, which gave us feed back on how our customers were feeling about our progress, and also reinforced to them how much and how well we were taking care of their needs, by having them assess our progress.

Posted on Monday, October 8, 2007 3:50 PM Agile Development | Back to top

Comments on this post: Using Scrum on a multi project development team

# re: Using Scrum on a multi project development team
Requesting Gravatar...

our development department is currently organizing all developers in two Scrum teams that both are intended to work on multiple projects.
Right now we experience two projects being in trouble and all resources are assigned to work on these two projects which will (ofcourse) result in putting the other (waiting) projects into trouble as well.

How prioritized the issues from the different projects?
We have a "team PO" (vs. the typical Scrum project/product PO) who is currently doing this job but as he is also project manager of one of the projects in trouble he is not independent in his decisions.
Who is doing the resource planning across the projects (long term)?

Left by Felix on Dec 02, 2007 10:32 AM

# re: Using Scrum on a multi project development team
Requesting Gravatar...
One of the biggest values of Scrum, is that it raises the visibility of issues in such a way that upper management can can actually do something about the issue.

Your company obviously has issues that need to be addressed.

My first question is, "Who are your Scrum Masters?"

If you say, "We don't have a Scrum Master", "One of the developers acts as the SM" or "We used to have a Scrum Master" then it it's possible that the teams are doing some flavor of "Agile Development" but what ever that flavor is, it's probably *not* Scrum.

Assuming that you are indeed doing Scrum, then, the Scrum Master, should be raising a red flag that there is a problem, then it's up to the company, and / or the PO, and / or the team, to figure out a solution.
Left by Malcolm Anderson on Dec 02, 2007 6:15 PM

# re: Using Scrum on a multi project development team
Requesting Gravatar...
It looks like I didn't answer the "resource planning" question as it didn't make much sense to me. I haven't finished Ken's book on Scrum and the Enterprise yet, that may answer those PMBOK sounding questions.

In Scrum, you have your team, you have a backlog, and after a couple of sprints you have a derived velocity. Now you know how long it will take you to complete your backlog assuming that nothing new is added to the list.

Your product owner holds the vision of what the end result of the product is, and make the hard decisions as to what should be on the top of the list.

The team makes the hard decisions of, "How much do we think we can really accomplish during the course of this sprint"

Left by Malcolm Anderson on Dec 02, 2007 6:37 PM

Your comment:
 (will show your gravatar)

Copyright © Malcolm Anderson | Powered by: