Loading ...
Sorry, an error occurred while loading the content.

21413Re: Multiple Projects & Sprints

Expand Messages
  • Casey Manus
    May 9 10:31 AM
    • 0 Attachment
      My 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 scrumdevelopment@yahoogroups.com, "Nicholas Cancelliere"
      <nickaustin74@...> wrote:
      > Casey,
      > Can you briefly describe these projects in terms of product owners
      > stakeholders? Do the 4 different projects have 4 different product
      > 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
      > 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
      > 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
      > 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
      > sprint planning. This way each Product Owner gets a little
      something and
      > can also have a realistic expectation of the velocity of the team
      > "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
      > 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
      > 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:
      > >
      > > All,
      > >
      > > My company has committed to using Scrum as our methodology and
      are in
      > > the forming stages of getting development kicked off on several
      > > 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
      > > 6 developers and a few ancillary staff members (dbas, QA, etc)
      > > 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
      > > projects into the product backlog. This appeals to me because it
      > > 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
      > > such a small team, and breaking into multiple teams seems bad at
      > > current size.
      > >
      > > 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 more
      > >
      > > 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
      > Rings)
    • Show all 11 messages in this topic