On Tue, 28 Dec 2004 04:01:26 -0500, Thomas Robbs
<[EMAIL PROTECTED]> wrote:
> > What's the impact of an inability to prioritize? What happens if we
> > insist on getting all these at once? The direct impact is an increase
> > in risk: we risk shuttering the business for a spelling change. That's
> > hardly what the real customer wants. There are indirect impacts as
> well: [...]
> These are all great questions, which are deserving of further analysis.
> I'm just not sure how you are drawing you relationship to bundling and
> unbundling.
Well, in the case at hand, the customer proxy was bundling things that
would be better left unbundled. ("I won't release unless I get all
this stuff: they're all equally important.")
> If I may, when I first read the article, I drew my own conclusion that
> the prioritization process may be an exercise in bundling, unbundling,
> and re-bundling -- a careful dance between customer and development
> team. My colleague, while agreeing that there might be connections
> across the topics, he stopped me from prematurely connecting the dots.
I might say that the "planning" process is an exercise in bundling
etc., and prioritization is part of that. And I agree that the "dance"
is often there (but sometimes there's no dance as one side can't see
the value).
I have on occasion heard (from both the customer side and the
development side) that they don't see the value in breaking something
up. But the ability to unbundle can unlock extra value and reduce
risk.
> Which brings me to the second point...
>
> How does the choice to bundle or not relate to prioritization? The
> conclusions seem after-the-fact (i.e. post prioritization) rather than
> re-focusing on the prioritization problem.
I'd say there's two ends to it. One is just the question of what you
decide goes together in, say, a release. This may be a loose bundling
(though sometimes it's more coupled than that).
Another issue is that the stories are not a given. Reworking a story
by unbundling its pieces can let you prioritize the whole thing
differently. (This splitting can happen during the planning
conversation.)
Consider two stories A and B versus their "split" versions A1, A2, A3,
and B1, B2, B3. If you work with big chunks, you have one decision: "A
then B" or "B then A"? If you work with finer pieces, you have a bunch
of alternatives; A1/A2/A3/B1/B2/B3 and B1/B2/B3/A1/A2/A3 are only two
of the possibilities. If you unbundle, you may decide B3+A2 is the
most valuable piece, deliver it first, and start booking revenue
sooner.
> Hope this is clearer than the skies over LA this evening. Thanks for the read!
And I hope my reply was as clear as Virginia's bright blue sky today.
And thanks for reading!
--
Bill Wake [EMAIL PROTECTED] www.xp123.com
To Post a message, send it to: [EMAIL PROTECTED]
To Unsubscribe, send a blank message to: [EMAIL PROTECTED]
ad-free courtesy of objectmentor.com
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
