21410Re: [scrumdevelopment] Multiple Projects & Sprints
- May 9, 2007Casey,Can you briefly describe these projects in terms of product owners and stakeholders? Do the 4 different projects have 4 different product owners? Do they have 4 different set of stakeholders?Knowing this would help in my reply to you.You are right to be concerned about having such a small team pulled in 4 different directions. It will not prove to be productive. Has the company considered it's taking on too much by having 4 different projects with such a small team? I wouldn't split up the team. Make sure they're focused on one sprint backlog (which can be derived from various product backlogs).If the projects themselves are small is there just one Product Owner organizing the requirements? If so then I'd suggest having a single backlog and the team works on the features in priority order set by the Product Owner. Even if there are 4 different Product Owners, see if you can't get just *one* person to be the "last word" and setter of priorities.If there are 4 competing product owners (who don't agree on priority) then create 4 backlogs and have the team pick from the top of each in their sprint planning. This way each Product Owner gets a little something and can also have a realistic expectation of the velocity of the team (for "their stuff"). It will be likely 1/4 of what it would be if they had the whole team dedicated to their backlog.You can track the progress of the product backlogs using a burndown, and then the sprint using it's own (for a total of 5). This way each Product Owner will be able to see how fast his stuff is getting done, and the team of course needs to track their progress daily in the sprint.I think what will happen is that your company will quickly realize it either needs to a) focus on just one project at a time or b) hire more developers.Not understanding the size or nature of the projects though means my interpretation/advice may or may not be relevant.Good luck!Nicholas
On 5/9/07, Casey Manus <caseymanus@...> wrote:
My company has committed to using Scrum as our methodology and are in
the forming stages of getting development kicked off on several large
projects. This comes after a technology shift in the company so we are
starting from scratch on all the projects.
We have some staffing concern, at least 4 projects with currently only
6 developers and a few ancillary staff members (dbas, QA, etc) that
will be involved in the projects, so that increases our total team size
to maybe 8 or 9 at maximum.
How do we handle this situation...I see a couple scenarios
1. One Sprint Team, running 1 sprint at time...putting items from all
projects into the product backlog. This appeals to me because it means
we have high visibility into items which are similiar enough to be
shared between projects.
2. Run concurrent sprints for each project. I worry about this with
such a small team, and breaking into multiple teams seems bad at our
We will be growing, so we will eventually be able to split into more
than one team, but that isn't going to happen for a few more months.
What advise can I get?
Nicholas Cancelliere, Austin TX
"The wide world is all about you: you can fence yourselves in, but you cannot for ever fence it out." -Gildor, Fellowship of the Ring (Lord of the Rings)
- << Previous post in topic Next post in topic >>