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.