RE: [scrumdevelopment] Multiple Customers in one Sprint - questions
I take it that there are "shared stories" in your Scrum implementation?
It is tricky, but possible to satisfy multiple projects/clients that
have Shared Backlog.
(Chapter 7. in the Scrum book talks about handling multiple concurrent
Here are some of the tricks we use:
note: "backlog" below means both product and sprint backlogs
- make all project Sprints coincide in time
- Shared Backlog is any stories/tasks that affect 2 or more projects
- Global Backlog is all stories/tasks for all projects
- Project Backlogs are views of the Global Backlog
that contain the project-specific backlog + the shared backlog
relevant to that project
- each project runs Scrum on their project backlog(s)
- Demos for projects only include features that are in effect for
- a "Scrum of Scrums" is held to manage the "shared backlog"
- a shared services team is necessary when the contributions
of the independent projects are owned by a central group
- any changes on Shared Backlog items triggers global testing
Here are some examples of some of our clients/companies where these
techniques have been applied successfuly:
Nike Securities 1997/1998
Northwest Bank 1999
Lincoln Re. 1999
Hipaa Accelerator 2001-date
More info on this at:
From: Deb [mailto:deborah@...]
Sent: Tuesday, September 09, 2003 12:44 PM
Subject: [scrumdevelopment] Multiple Customers in one Sprint - questions
I'm using Scrum in a "support and development" group, where one
Sprint could conceivably produce different software products for two
different groups - say, Sales and Finance.
In looking ahead, this seems problematic in terms of efficient use of
resource time for Sprint Planning/Demo/Review meetings. Either we'd
Plan/Demo/Review all Customers' work (and alternatively bore one and
then the other Customer) or we'd need to have two sets of these
meetings, each focused on a given Customer. I'd think the latter
would be better, as wasting Customer time does not make a good case
for Scrum's efficiency.
Something feels strange here. I'd guess it's better for a Sprint to
be serving a single Customer... and we could run two parallel
Sprints, each focusing on one Customer. But this scenario would occur
when work for one customer does not fill a whole sprint...
Can anyone share their insight on this or point me to an
article/discussion pertinent to multi-customer sprint planning?
(oh, the conundrums we encounter in the REAL world of Scrum! :-)
Yahoo! Groups Sponsor
To Post a message, send it to: scrumdevelopment@...
To Unsubscribe, send a blank message to:
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.