Excellent question. I'd say "it depends".
If you have two customers for the same basic product, then Brad's answer
applies - you either need a product manager to make the decisions, or you
need to involve both customers in the decision making process. It's good to
get the customers together in a room if possible, because then they see the
bigger picture; a change suggested by one may actually benefit the other,
and in any case they will have some exposure to each others' needs, which
makes it more palatable when their requests are not always acted on
immediately. I've seen this work well for both feature planning and also
prioritizing defect fixes. Obviously this is much easier to do for internal
However, if I understand you correctly, you are actually working on
different products, so each customer doesn't really care about the other
except that they are competing for attention. (I'm assuming there isn't
enough steady work to justify multiple teams.) Then it is purely a matter
of business priorities. Somehow you need to prioritize requests based on
the ratio of business value to effort. You might get direction from
management on these priorities; failing that, you can try to estimate them
yourself (you'll need the customers to supply the estimated value). You may
want to ensure at least some work gets done for each customer each sprint -
to keep their involvement going. As Brad's article mentions, the decision
making process must be made visible to the customers so they don't feel
From: Deb [mailto:deborah@...
Sent: 2003/09/09 1: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! :-)