21413Re: Multiple Projects & Sprints
- May 9 10:31 AMMy projects are large state goverment contracts and must be worked on
concurrently due to the timelines already committed to by prior
management. Again, its the "when can you have this done by Friday"
mentality. My hope is that Scrum will help us figure out early
enough what the real timeline will be so we can adjust resources as
needed to make our line in the sand for each project. There is a lot
of overlap between these projects as they are the same type of
system, meaning you could probably share alot of the work from one
project to the next. We are in a sense building our "core" product
while fulfilling the state contracts.
Since we are an ISV, our product owner isn't really clear, we have a
project manager that manages the relationship with each state, so
they contribute items to the backlog, but I guess for now the
development manager is acting as the product owner. I want us to
define that person more, the leader of the PMO seems like a likely
candidate. We have this weird environment because we have a mix of
agile and other processes that are forced upon us by the contracts
that have been signed. Our commitment is that we are an agile
development team and they PMO is to manage all the noise around that,
including the fluff that is required by the contracts.
I am probably mixing alot of information in that description of our
--- In email@example.com, "Nicholas Cancelliere"
> Can you briefly describe these projects in terms of product owners
> stakeholders? Do the 4 different projects have 4 different productowners?
> Do they have 4 different set of stakeholders?in 4
> Knowing this would help in my reply to you.
> You are right to be concerned about having such a small team pulled
> different directions. It will not prove to be productive. Has thecompany
> considered it's taking on too much by having 4 different projectswith such
> a small team? I wouldn't split up the team. Make sure they'refocused on
> one sprint backlog (which can be derived from various productbacklogs).
> If the projects themselves are small is there just one Product Owner
> organizing the requirements? If so then I'd suggest having a
> and the team works on the features in priority order set by theProduct
> Owner. Even if there are 4 different Product Owners, see if youcan't get
> just *one* person to be the "last word" and setter of priorities.priority) then
> If there are 4 competing product owners (who don't agree on
> create 4 backlogs and have the team pick from the top of each intheir
> sprint planning. This way each Product Owner gets a littlesomething 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 theyhad the
> whole team dedicated to their backlog.burndown, and
> You can track the progress of the product backlogs using a
> then the sprint using it's own (for a total of 5). This way eachProduct
> Owner will be able to see how fast his stuff is getting done, andthe team
> of course needs to track their progress daily in the sprint.it either
> I think what will happen is that your company will quickly realize
> needs to a) focus on just one project at a time or b) hire moredevelopers.
> Not understanding the size or nature of the projects though means my
> interpretation/advice may or may not be relevant.
> Good luck!
> On 5/9/07, Casey Manus <caseymanus@...> wrote:
> > All,
> > My company has committed to using Scrum as our methodology and
> > the forming stages of getting development kicked off on severallarge
> > projects. This comes after a technology shift in the company sowe are
> > starting from scratch on all the projects.only
> > We have some staffing concern, at least 4 projects with currently
> > 6 developers and a few ancillary staff members (dbas, QA, etc)that
> > will be involved in the projects, so that increases our totalteam size
> > to maybe 8 or 9 at maximum.all
> > How do we handle this situation...I see a couple scenarios
> > 1. One Sprint Team, running 1 sprint at time...putting items from
> > projects into the product backlog. This appeals to me because itmeans
> > we have high visibility into items which are similiar enough to bewith
> > shared between projects.
> > 2. Run concurrent sprints for each project. I worry about this
> > such a small team, and breaking into multiple teams seems bad atour
> > current size.more
> > We will be growing, so we will eventually be able to split into
> > than one team, but that isn't going to happen for a few moremonths.
> > What advise can I get?
> Nicholas Cancelliere, Austin TX
> "The wide world is all about you: you can fence yourselves in, but
> cannot for ever fence it out." -Gildor, Fellowship of the Ring(Lord of the
- << Previous post in topic Next post in topic >>