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

21409Re: Multiple Projects & Sprints

Expand Messages
  • dnicolet99
    May 9, 2007
    • 0 Attachment
      I think you will find that by working through your project portfolio
      one at a time (per team) you will actually get through all the work in
      a shorter time than you would by running multiple projects
      concurrently. That approach also eliminates the problem of
      cross-project "noise" when you report status to management.

      The team size you mention sounds good. If it grows beyond about 12
      altogether you might consider dividing it into two. Depending on the
      scope of individual projects, you could divide it into two before
      that; you could even do it now, and have 2 to 4 developers on each
      team. I can't say for sure because I don't know what your portfolio
      looks like.

      Dave

      --- In scrumdevelopment@yahoogroups.com, "Casey Manus"
      <caseymanus@...> wrote:
      >
      > Another big concern is reporting, how do we show our sprint burndown
      > to the stakeholders of project1 without the noise of project2?
      >
      > This alone may drive us to running multiple sprints with the same
      > team members, but that feels awkward.
      >
      > -Casey
      >
      >
      > --- In scrumdevelopment@yahoogroups.com, "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
      > 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
      > > current size.
      > >
      > >
      > > 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?
      > >
      >
    • Show all 11 messages in this topic