All reasonable points. One additional point that could be helpful. When the teams do their estimates, have them look for and identify dependencies. ForMessage 1 of 4 , Jun 29, 2008View SourceAll reasonable points. One additional point that could be helpful. When the teams do their estimates, have them look for and identify dependencies. For example, if there are interfaces that impact multiple teams, or components the some teams need. We try to break those dependencies where possible, perhaps by determining priorities across the interfaces so that teams can come to an agreement on the first version of the interface, knowing it will evolve over time. This is splitting the work and breaking dependencies by prioritizing the data to be shared.
Robin Dymond, CST
Ass't Producer, Learning and Education, Agile 2008On Sat, Jun 28, 2008 at 9:12 AM, Jim Schiel <schiel@...> wrote:
I'm pretty much in agreement with what Felix said, Mike. What I would add to the equation is this -- waterfall based development teams do things by dates. Scrum development teams do things by priority. When a non-Scrum team (PM or PO) wants something from a Scrum team, the non-Scrum PM should write the story and provide it to the PO of the supplying Scrum team with a date upon which the completed software needs to be returned. This becomes useful information for the PO to decide how and if they can schedule the story and if they can get it done per the non-Scrum team's schedule.Of course, some negotiation of the date may be necessary because of the PO's own prioritizations, but that's between the PO and the non-Scrum PM.One other important point -- the non-Scrum PM needs to be available during backlog grooming to answer the team's questions about the story.Lastly, if the reverse happens, and the Scrum teams needs something from the non-Scrum team, that should also be represented with a story on the Scrum team's backlog. The effort can be set to 0, but you should use your current release plan to provide a date to the non-Scrum team PM by which you need the story to be completed. Typical backlog grooming will surface this story with two or three months lead time, which can be used by the Scrum Master or the PO to check back with the non-Scrum PM on progress or possible date changes.Have fun!Jim--On Sat, Jun 28, 2008 at 11:10 AM, Felix <faruessel@...> wrote:
what you describe is not far away from the situation we have to deal
with: Several Scrum teams working on several projects each
(development/maintenance/support) in every sprint.
To finish stories very often highly complex input (components, data,
infrastructure) is required and most of this input is creating a lot
of dependencies to other teams. This is not the way Scrum was
originally planned to be used but it works fairly ok.
The teams that require deliveries from other team add the
corresponding stories into each other backlogs (and sometimes they ask
for fixed support stories). These stories are estimated by the team
that works on them. Priority has to be discussed with the PO of the
team that works on the story. I know both sides of this game as I am a
"classical" project manager in some projects with stories that are
worked on in multiple scrum teams and I am a product owner with a
fantastic team working on one of my major projects.
In your case the same approach should work: Ask the project manager to
write stories (he may add constrains/requirements as he needs to) and
let the teams estimate the stories. After you received the estimates
the story can be considered in release planning. No big deal at all
because it is the standard approach. The project manager just needs to
understand that he does not have the right to assign single developers
based on HIS project plan to work on specific tasks. However, if he
gets the right priorities within his organization, that should be no
problem for him (do you have a project portfolio management or a
He will probably need some training in writing good stories – you
should invest a lot of time here.
--- In email@example.com, "Mike Freislich"
> I am coaching Scrum at an organisation at which I have introduced 5
> Scrum so far. Although there are some lack-of-autonomy issues in the
> team structure, each team has their own estimated, prioritised backlog,
> Product Owner and Scrum Master. I am working on each autonomy issue
> teams and management. However, what I have noticed most recently is that
> there is a project in the organisation that up until now has not been
> running with Scrum. Gantt charts are prevalent and PMBok project
> are moaning about slipping deadlines (what's new). What is most
> about this project is that it requires the collaboration of all of
> teams in order to be completed. The work on the Gantt charts has been
> getting assigned directly to team members of the Scrum Teams and is
> undermining the ability for teams to predictably deliver the work
> PO's have prioritised, essentially creating multiple priorities for
> members. This is not good, and the organisation agrees.
> Yes, And. I have suggested that the project manager for this initiative
> becomes a Product Owner. We have assembled a small task force with
> representatives from all of the teams, in order to help the PO
> initial Product Backlog. The intention is that we can then allocate the
> items from this backlog to the relevant team backlogs, and have the
> responsible teams perform the estimation. Once the items are
> can be scheduled (prioritised) within their backlogs. The PO's from
> the working teams and the PO for the enterprise scale initiative can
> negotiate priority of the items across their up-coming Sprints and
> synchronise the effort. This should then place the priority decision
> squarely in the business and allow each team to work from a single
> prioritised list.
> My questions are:
> - The Enterprise-scale backlog will have estimates on it from
> multiple teams, each with a subjective scale. This will make it
> have a clear centralised schedule of work for this initiative, based
> estimates outside of the context of all of the team backlogs. Should
> scheduling across the Sprints of each team, and then allocating the
> dates to the enterprise backlog items in order to manage the
> the enterprise work?
> - Does what I am doing make sense i.e. Is there a better way of
> doing this?
> PS. I feel that the best solution to this problem would be to create one
> cross-functional team with dedicated members, and drive them with a
> Backlog. I have recommended this, but management won't bend. "A dead
> Master is a useless Scrum Master" - Ken Schwaber.
> Help would be appreciated.
CST, Danube Technologies
Look for Danube at Agile2008 - Toronto | August 4 though 8 - Click, Get Involved, Win Stuff! - www.danube.com/agile08