planning tasks versus stories

[Keith Ray]

questions from a skeptic:

But if the work is done in technical tasks, and you can't specify the
technical tasks in Release Planning, then you can't specify the amount
of work.  So what are we specifying and estimating when we specify the
user stories?
 
There is an assumption that the customer will specify a detailed list,
missing nothing, broken down into small chunks.  I don't believe that
will be our experience.  If the customer can actually do this then the
customer can arrive at the estimate independently.

I know XP assumes that stuff can be added later, we can break things
down further in iteration planning, etc.   But in breaking things down
to small chunks we are arriving at estimates.   What are those
estimates based on?   SWAGs, right?   SWAGs based on tasks that we
can't specify the technical details to.

All this is supposed to be fine because of the velocity tracking.  But
that assumes that story points are somehow consistent.  So that it is
possible to aggregate them and say things like "we need to do 4 story
points a week to arrive at completion".    I don't see the basis for
this.   I'd ask for data showing the deviation but given the variables
(the engineers at the company, the PD, the difficulty of the tasks,
the existing code, the language being used, the management overhead,
how many people get hit by buses, the experience of the team with the
code) I don't see how one data set can apply to another one.

What is the point?  If it is to track progress, but we are leaving out
chunks and the points themselves are variable, then what is all this
for?   It all seems like a way to compensate management and the
project manager by giving them an illusion of control.  What is the
cost of this illusion of control as a percentage of engineering time? 
There is a good chance that this kind of data will be used to make
decisions to kill features.

[Ron Jeffries]

On Wednesday, February 16, 2005, at 3:00:44 PM, Keith Ray wrote:

> questions from a skeptic:

> But if the work is done in technical tasks, and you can't specify the
> technical tasks in Release Planning, then you can't specify the amount
> of work.  So what are we specifying and estimating when we specify the
> user stories?

When we estimate user stories, we're estimating how big the
technical tasks will be to implement the stories.

>  
> There is an assumption that the customer will specify a detailed list,
> missing nothing, broken down into small chunks.  I don't believe that
> will be our experience. 

I've seen many teams accomplish this and have never seen one fail to
if they tried. What is it about your situation that makes you think
it won't happen?

> If the customer can actually do this then the
> customer can arrive at the estimate independently.

I don't see how ... how will the customer know how long the chunks
will take to do?

> I know XP assumes that stuff can be added later, we can break things
> down further in iteration planning, etc.   But in breaking things down
> to small chunks we are arriving at estimates.   What are those
> estimates based on?   SWAGs, right?   SWAGs based on tasks that we
> can't specify the technical details to.

Yes. But suppose you got them down to a range where you were sure
they were no more than a week each. How far off will your guesses
likely be? How often?

> All this is supposed to be fine because of the velocity tracking.  But
> that assumes that story points are somehow consistent.  So that it is
> possible to aggregate them and say things like "we need to do 4 story
> points a week to arrive at completion".    I don't see the basis for
> this.   I'd ask for data showing the deviation but given the variables
> (the engineers at the company, the PD, the difficulty of the tasks,
> the existing code, the language being used, the management overhead,
> how many people get hit by buses, the experience of the team with the
> code) I don't see how one data set can apply to another one.

Suppose there are a 100 stories in a project, with a mean size of 3
days. Suppose any reasonable distribution of estimate you like about
that mean. What will the effect of the law of large numbers be on
the predicted date given a few weeks of story-building experience?

> What is the point?  If it is to track progress, but we are leaving out
> chunks and the points themselves are variable, then what is all this
> for?  

If your assumptions were correct, things would be as bad as you
suggest, but in my experience teams do break stories down, they do
tend to have estimates that are proportional to each other, they do
manage to go at approximately a constant rate, and they do improve
in estimation as they go along.

In short, in my experience, things aren't as bad as you suggest.

> It all seems like a way to compensate management and the
> project manager by giving them an illusion of control.  What is the
> cost of this illusion of control as a percentage of engineering time? 

1/2 team day per week or less, according to my experience. But it
isn't an illusion.

> There is a good chance that this kind of data will be used to make
> decisions to kill features.

Yes. That's good, I think. Do you think it isn't?

Ron Jeffries
www.XProgramming.com
One test is worth a thousand expert opinions.
-- Bill Nye (The Science Guy)



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/xpbookdiscussiongroup/

<*> To unsubscribe from this group, send an email to:
xpbookdiscussiongroup-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:

[Keith Ray]

Good answers, which I'll forward to the skeptic.

One point not mentioned previously is the existance of a large amount
of legacy code, some large portion of which has to be re-architected
in order to implement certain new features. Experiences with that
legacy code include times when some "small thing" turns out to be a
large amount of work.


On Wed, 16 Feb 2005 15:41:35 -0500, Ron Jeffries
<ronjeffries-***@public.gmane.org> wrote:
[....]
>
>
> Yes. That's good, I think. Do you think it isn't?
>
> Ron Jeffries
> www.XProgramming.com
> One test is worth a thousand expert opinions.
> -- Bill Nye (The Science Guy)
>
>
> Yahoo! Groups Links
>
>
>
>
>


--

C. Keith Ray
<http://homepage.mac.com/keithray/blog/index.html>
<http://homepage.mac.com/keithray/xpminifaq.html>
<http://homepage.mac.com/keithray/resume2.html>

[Ola Ellnestam]

Hi all,

I've been lurking in the back just listening to you guys but finally I
feel I got some contribution to make. I recognize this problem from a few
projects I've been working in.

>
> One point not mentioned previously is the existance of a large amount
> of legacy code, some large portion of which has to be re-architected
> in order to implement certain new features. Experiences with that
> legacy code include times when some "small thing" turns out to be a
> large amount of work.
>
>

Small things always turn out to be big things even if your not working
with legacy code. There's not really that big difference. Your velocity
will probably drop if you're working with many 'legacy stories'.

But using the 'Yesterdays weather'-method will still work.

And you will notice that the velocity stabilizes after a few iterations
and you get more and more comfortable estimating the stories as you go.

Hope I've been of some help?

//Ola


> On Wed, 16 Feb 2005 15:41:35 -0500, Ron Jeffries
> <ronjeffries-***@public.gmane.org> wrote:
> [....]
> >
> >
> > Yes. That's good, I think. Do you think it isn't?
> >
> > Ron Jeffries
> > www.XProgramming.com
> > One test is worth a thousand expert opinions.
> >   -- Bill Nye (The Science Guy)
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
>
>
> --
>
> C. Keith Ray
> <http://homepage.mac.com/keithray/blog/index.html>
> <http://homepage.mac.com/keithray/xpminifaq.html>
> <http://homepage.mac.com/keithray/resume2.html>
>
> Yahoo! Groups Sponsor
> ADVERTISEMENT
> [&time=1108600351830660]
> [rand=912705116]
>
> _________________________________________________________________________________________________________________
> Yahoo! Groups Links
> * To visit your group on the web, go to:
> http://groups.yahoo.com/group/xpbookdiscussiongroup/
>  
> * To unsubscribe from this group, send an email to:
> xpbookdiscussiongroup-unsubscribe-***@public.gmane.org
>  
> * Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>

[nigel_w_thorne]

To clairfy my question...

>From Kents comment "Packing iterations with only the most important
stories guarantees that if something goes wrong, something important
will have to be dropped."

If you are traiding lower qriority stories for higher ones just so you
can introduce slack, then surely you aren no longer delivering the
most value you can from each iteration? Assuming you do get everything
complete you have failed to deliver the most business value you could
have in that iteration.

I can understand the problem of having too many big stories in the
same itteration. You end up with a large story not done if you slip,
which would have a big effect on your velocity. Putting a few small
stories into the iteration so they can be dropped if slippage happens
therefore makes sence.

It seems to me that Slack is intended to deal with this 'granularity'
issue. Am I right?

To achieve both goals (priority and granularity) wouldn't you just
split the story that doesn't fit into several smaller stories and
prioritise those? At least then you are constantly working on the
highest value functionality.

Anyone?

--- In xpbookdiscussiongroup-***@public.gmane.org, Nigel Thorne
<***@g...> wrote:
> By adding slack to an iteration aren't you still dropping something
important for something less valuable?

[Kent Beck]

> -----Original Message-----
> From: nigel_w_thorne [mailto:nigel.thorne-***@public.gmane.org]
> Sent: Thursday, February 17, 2005 12:44 PM
> To: xpbookdiscussiongroup-***@public.gmane.org
> Subject: Re: [xpe2e] Planning game confusion
>
> It seems to me that Slack is intended to deal with this 'granularity'
> issue. Am I right?

That's not how I think of it. I think of slack as dealing with the
predictability problem. Strong relationships require commitment and follow
through, but we know that we work in an unpredictable world. Slack is one
way to reconcile these two contradictory facts.

Kent Beck
Three Rivers Institute

[J. B. Rainsberger]

nigel_w_thorne wrote:
>
> To clairfy my question...
>
>>From Kents comment "Packing iterations with only the most important
> stories guarantees that if something goes wrong, something important
> will have to be dropped."
>
> If you are traiding lower qriority stories for higher ones just so you
> can introduce slack, then surely you aren no longer delivering the
> most value you can from each iteration?

The bond of trust between the programmers and the customers is perhaps
more valuable than the value we can deliver in a given iteration. I
would prefer to be able to quantify that. Perhaps I can.

Suppose we deliver $100k of value per iteration.
Suppose we committed to delivering $150k of value per iteration.
Even though we're delivering $100k for value per iteration, after four
iterations our customer says, "Bag this; you guys never come in on time."

Instead of delivering $2.5M of value in a year's worth of two-week
iterations, we only delivered $400k. We might have delivered the $2.5M
in value had we simply set our sights lower and kept our commitments.
--
J. B. (Joe) Rainsberger
Diaspar Software Services
http://www.diasparsoftware.com
Author, JUnit Recipes: Practical Methods for Programmer Testing

[Ron Jeffries]

On Tuesday, March 15, 2005, at 3:38:24 PM, J. B. Rainsberger wrote:

> The bond of trust between the programmers and the customers is perhaps
> more valuable than the value we can deliver in a given iteration. I
> would prefer to be able to quantify that. Perhaps I can.

> Suppose we deliver $100k of value per iteration.
> Suppose we committed to delivering $150k of value per iteration.
> Even though we're delivering $100k for value per iteration, after four
> iterations our customer says, "Bag this; you guys never come in on time."

> Instead of delivering $2.5M of value in a year's worth of two-week
> iterations, we only delivered $400k. We might have delivered the $2.5M
> in value had we simply set our sights lower and kept our commitments.

I'm pretty sure no one is suggesting over-committing as a viable
strategy. This team didn't estimate accurately and apparently didn't
learn from it.

I hear you suggesting offering less than we know we can do. Is that
what you're getting at?

Ron Jeffries
www.XProgramming.com
No one expects the Spanish Inquisition ...

[J. B. Rainsberger]

Ron Jeffries wrote:
> On Tuesday, March 15, 2005, at 3:38:24 PM, J. B. Rainsberger wrote:

> I'm pretty sure no one is suggesting over-committing as a viable
> strategy. This team didn't estimate accurately and apparently didn't
> learn from it.

Indeed.

> I hear you suggesting offering less than we know we can do. Is that
> what you're getting at?

Perhaps. I think we have to recognize when we don't yet have the trust
of the customer (and her bosses up the chain) and perhaps underpromise
until we gain some of that trust.
--
J. B. (Joe) Rainsberger
Diaspar Software Services
http://www.diasparsoftware.com
Author, JUnit Recipes: Practical Methods for Programmer Testing

[Ron Jeffries]

On Wednesday, March 16, 2005, at 10:02:59 AM, J. B. Rainsberger wrote:

>> I hear you suggesting offering less than we know we can do. Is that
>> what you're getting at?

> Perhaps. I think we have to recognize when we don't yet have the trust
> of the customer (and her bosses up the chain) and perhaps underpromise
> until we gain some of that trust.

OK ... I understand the idea.

Ron Jeffries
www.XProgramming.com
It's easier to act your way into a new way of thinking
than to think your way into a new way of acting. --Millard Fuller

[Kent Beck]

Yes, when you put in slack stories, you are giving up a more valuable
feature in return for predictability and confidence. I think predictability
and confidence are valuable, and generally more valuable than the third (or
eighth story) on the list. If absolutely all of these absolutely critical
features absolutely have to be done this week, your project is already in
trouble.

I described slack at a workshop here in southern Oregon attended by
Francesco Cirillo. Some people's initial reaction was very negative--isn't
this just sandbagging? Then Francesco said, "That's exactly what we are
doing right now. It's very important for us to deliver this week, so we
scheduled one tiny bit of new functionality and lots of cleanup work."

We deliver functionality but we build relationships. Planning is more about
building relationships than it is about delivering functionality.

Kent Beck
Three Rivers Institute


_____

From: Nigel Thorne [mailto:nigel.thorne-***@public.gmane.org]
Sent: Tuesday, February 15, 2005 4:09 PM
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: Re: [xpe2e] Planning game confusion


By adding slack to an iteration aren't you still dropping something
important for something less valuable?

[Ron Jeffries]

On Thursday, February 17, 2005, at 11:42:14 PM, Kent Beck wrote:

> Yes, when you put in slack stories, you are giving up a more valuable
> feature in return for predictability and confidence. I think predictability
> and confidence are valuable, and generally more valuable than the third (or
> eighth story) on the list. If absolutely all of these absolutely critical
> features absolutely have to be done this week, your project is already in
> trouble.

Don't get me wrong. I'm all for slack in the sense I understand from
DeMarco. Adding it as a primary practice is of value to me. Now in
the book, Kent refers to scheduling "minor tasks that can be
dropped", not "less important stories", so that may be part of
what's confusing me here.

I would think, therefore, that I might habitually schedule "time"
out of the day that was intended for slack, and might have "tasks"
that folks could focus on, such as a refactoring board or such, but
that I would not schedule any low-priority customer story with
intention that it might be dropped. Scheduling a high-priority story
with intention that it might be dropped delivers more value.

What am I missing?

> I described slack at a workshop here in southern Oregon attended by
> Francesco Cirillo. Some people's initial reaction was very negative--isn't
> this just sandbagging? Then Francesco said, "That's exactly what we are
> doing right now. It's very important for us to deliver this week, so we
> scheduled one tiny bit of new functionality and lots of cleanup work."

I'm not sure that's slack. A good choice of priorities, but is it
slack?

> We deliver functionality but we build relationships. Planning is more about
> building relationships than it is about delivering functionality.

Under-promise and over-deliver is a famous phrase that reminds us of
two truths.

First, people's response to minor deviations from expectations is
not linear around zero. A small over-delivery is good, but a small
under is more bad.

Second, the only way to always end up above target is to set the
target below what's attainable.

However, there could be an element of untruth in how one expresses
this notion. Sandbagging, as I understand it, occurs when I hold
back some of my capability without revealing it to the customer, so
that I have contingency resources left. We don't want that: we want
honesty. So we would like the team, customer plus developers, to
hold back some of /their/ capability, to provide contingency
resources.

I feel that I'm standing at the edge of a slippery slope.

Ron Jeffries
www.XProgramming.com
To Fly, Flip Away Backhanded -- Master Frisbee

[Tim King]

Ron Jeffries wrote:
> First, people's response to minor deviations from expectations is
> not linear around zero. A small over-delivery is good, but a small
> under is more bad.

I have worked where this is true in the extreme. That is, people would
heap blame on you if you under-delivered even in the least.

I have also worked in (more productive) environments where stakeholders
took deviations in stride, planning for them rather than getting upset
about them. The key here was to identify stories that had real schedule
dependencies, that were part of the critical chain, and make sure there
was enough contingent slack built into the overall schedule chain. Other
stories, even important ones, had some innate schedule flexibility, and
everyone realized this. We could then put the most important stories
first, all the time, even if an important story got pushed out. Some
group cultures cannot use this process.

-TimK
--
J. Timothy King ..team-oriented..object-oriented..Agile..
www.jtse.com ..C++..Perl..Java..assembly..embedded.systems..

[Nigel Thorne]

I too feel uneasy about this idea. Why do we (the team) decide that
this iteration is the one that I shouldn't schedule a full iteration's
work for?

I think the answer is in risk. Estimates being one value is a
simplification which works for most situations. We seem to be
discussing the situation where: to schedule the iteration to contain
the highest priority stories would introduce a level of risk within
the iteration that would be uncomfortably high.

Say you have three stories each with 20% chance of blow-out, then you
suddenly have 60% chance the iteration will blow out. That seems
unacceptable, but that seems to be a customer decision.

In this scenario I can see that you could either pick less stories for
the iteration and fill the rest with refactorings and technical tasks,
or skip some high priority stories in favor of lower priority ones
that contain less risk, so the overall risk is reduced.

Presented like this, it then becomes the customer decision what level
of risk they are comfortable with. (as with any other investment)

It also seem that it is the responcibility of the development team to
highlight risky stories so the customer can make an informed decision.

any feedback?
Nigel

On Fri, 18 Feb 2005 06:11:26 -0500, Ron Jeffries
<ronjeffries-***@public.gmane.org> wrote:
> On Thursday, February 17, 2005, at 11:42:14 PM, Kent Beck wrote:
>
> > Yes, when you put in slack stories, you are giving up a more valuable
> > feature in return for predictability and confidence. I think
> predictability
> > and confidence are valuable, and generally more valuable than the third
> (or
> > eighth story) on the list. If absolutely all of these absolutely critical
> > features absolutely have to be done this week, your project is already in
> > trouble.
>
> Don't get me wrong. I'm all for slack in the sense I understand from
> DeMarco. Adding it as a primary practice is of value to me. Now in
> the book, Kent refers to scheduling "minor tasks that can be
> dropped", not "less important stories", so that may be part of
> what's confusing me here.
>
> I would think, therefore, that I might habitually schedule "time"
> out of the day that was intended for slack, and might have "tasks"
> that folks could focus on, such as a refactoring board or such, but
> that I would not schedule any low-priority customer story with
> intention that it might be dropped. Scheduling a high-priority story
> with intention that it might be dropped delivers more value.
>
> What am I missing?
>
> > I described slack at a workshop here in southern Oregon attended by
> > Francesco Cirillo. Some people's initial reaction was very
> negative--isn't
> > this just sandbagging? Then Francesco said, "That's exactly what we are
> > doing right now. It's very important for us to deliver this week, so we
> > scheduled one tiny bit of new functionality and lots of cleanup work."
>
> I'm not sure that's slack. A good choice of priorities, but is it
> slack?
>
> > We deliver functionality but we build relationships. Planning is more
> about
> > building relationships than it is about delivering functionality.
>
> Under-promise and over-deliver is a famous phrase that reminds us of
> two truths.
>
> First, people's response to minor deviations from expectations is
> not linear around zero. A small over-delivery is good, but a small
> under is more bad.
>
> Second, the only way to always end up above target is to set the
> target below what's attainable.
>
> However, there could be an element of untruth in how one expresses
> this notion. Sandbagging, as I understand it, occurs when I hold
> back some of my capability without revealing it to the customer, so
> that I have contingency resources left. We don't want that: we want
> honesty. So we would like the team, customer plus developers, to
> hold back some of /their/ capability, to provide contingency
> resources.
>
> I feel that I'm standing at the edge of a slippery slope.
>
> Ron Jeffries
> www.XProgramming.com
> To Fly, Flip Away Backhanded -- Master Frisbee
>
>
>
>
> ________________________________
> Yahoo! Groups Links
>
> To visit your group on the web, go to:
> http://groups.yahoo.com/group/xpbookdiscussiongroup/
>
> To unsubscribe from this group, send an email to:
> xpbookdiscussiongroup-unsubscribe-***@public.gmane.org
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


--
Nigel Thorne
Extreme Programmer & Coach
www.nigelthorne.com

[Tim King]

Nigel Thorne wrote:
> Say you have three stories each with 20% chance of blow-out, then you
> suddenly have 60% chance the iteration will blow out. That seems
> unacceptable, but that seems to be a customer decision.

Actually the risk would be (1 - (1 - 0.2)^3), or a 48.8% chance the
iteration's estimates would _not_ be met.

And if you estimate your stories not optimistically, not
pessimistically, there's a 50% chance, by definition, any given story
will take longer than expected. If there are 3 stories in an iteration,
that's an 87.5% chance at least one story will have to be cut from the
iteration. (E.g., 0.5^3 chance of no stories being cut). If there are 10
stories, there's a 99.9% chance you'll cut at least one story.

So you definitely should include at least one story that can be cut,
because there's a high probability you'll need to do so. In some job
cultures, that means stating that you might get to it if you have time,
but don't expect anything. In others, it means scheduling less important
stories that can be cut. In yet others, cutting stories is considered
normal (which it is), and this means you measure your stability and
commitment in other ways (like project velocity or burn rate).

-TimK
--
J. Timothy King ..team-oriented..object-oriented..Agile..
www.jtse.com ..C++..Perl..Java..assembly..embedded.systems..

[Kent Beck]

> -----Original Message-----
> From: Ron Jeffries [mailto:ronjeffries-***@public.gmane.org]
> Sent: Friday, February 18, 2005 3:11 AM
> To: xpbookdiscussiongroup-***@public.gmane.org
> Subject: Re: [xpe2e] Planning game confusion
>
> I would think, therefore, that I might habitually schedule "time"
> out of the day that was intended for slack, and might have "tasks"
> that folks could focus on, such as a refactoring board or such, but
> that I would not schedule any low-priority customer story with
> intention that it might be dropped. Scheduling a high-priority story
> with intention that it might be dropped delivers more value.
>
> What am I missing?

You are investing in two things during an iteration: the features created by
the iteration and the relationships that will sustain and support future
iterations. If you "priority pack" (<- new phrase warning) each iteration,
some significant percentage of the time you aren't going to deliver stuff
the customer really wanted to see. That's bad for the relationship even if
those iterations that go completely smoothly are good for the feature list.

I think this is related to your recent quote about the Marine Corps. You
want to create the habit of winning. You can't do that if you are frequently
dropping stuff that really matters. As your estimates improve, you should be
able to get away with less and less slack, but, as they say in
manufacturing, any 100% utilized resource is a bottleneck.

>
> > I described slack at a workshop here in southern Oregon attended by
> > Francesco Cirillo. Some people's initial reaction was very
> negative--isn't
> > this just sandbagging? Then Francesco said, "That's exactly
> what we are
> > doing right now. It's very important for us to deliver this
> week, so we
> > scheduled one tiny bit of new functionality and lots of
> cleanup work."
>
> I'm not sure that's slack. A good choice of priorities, but is it
> slack?

It's slack because they deliberately scheduled less important items in order
to improve the probability of delivery. They were running up to an important
demo. If they delivered, all was well. If they didn't deliver the little bit
of functionality they wanted to deliver in the iteration it would look
really bad in the demo. Here's my assessment of the situation:

Deliver Don't Deliver
Feature +1 -1
Relationship +10 -10

That is, the one feature they picked would be nice for the demo but not
critical. However, completing the iteration as committed was very valuable
and not completing it was painful. In this case, lots of slack is the way to
create the most value.

Kent Beck
Three Rivers Institute

>
> However, there could be an element of untruth in how one expresses
> this notion. Sandbagging, as I understand it, occurs when I hold
> back some of my capability without revealing it to the customer, so
> that I have contingency resources left. We don't want that: we want
> honesty. So we would like the team, customer plus developers, to
> hold back some of /their/ capability, to provide contingency
> resources.
>
> I feel that I'm standing at the edge of a slippery slope.

Yes, and what keeps you from sliding down is integrity. If you treat your
customer respectfully, keep them fully informed of your progress and of
their options, and you do your best, then you don't have to fear the
consequences.

Kent Beck
Three Rivers Institute

[Nigel Thorne]

I think I am starting to understand. Thanks Kent for helping clarify
slack for us.

I have another question. How do you explain slack to the customer?

Assume you were starting a new project with a new team (so no trust is
yet established with the customer). Do you just approach it as "We
believe we can get 12 pair hours a week completed. I would like you to
pick 8 pair hours of high priority stories and 4 pair hours of less
important stories that we can drop in the event that any of the high
priority functionality overruns our estimate." ?

So I guess my question is... How do you explain it, and what reactions
do you tend to get?

Cheers
Nigel


On Tue, 1 Mar 2005 11:52:20 -0800, Kent Beck <kentb-***@public.gmane.org> wrote:
>
>
> > -----Original Message-----
> > From: Ron Jeffries [mailto:ronjeffries-***@public.gmane.org]
> > Sent: Friday, February 18, 2005 3:11 AM
> > To: xpbookdiscussiongroup-***@public.gmane.org
> > Subject: Re: [xpe2e] Planning game confusion
> >
> > I would think, therefore, that I might habitually schedule "time"
> > out of the day that was intended for slack, and might have "tasks"
> > that folks could focus on, such as a refactoring board or such, but
> > that I would not schedule any low-priority customer story with
> > intention that it might be dropped. Scheduling a high-priority story
> > with intention that it might be dropped delivers more value.
> >
> > What am I missing?
>
> You are investing in two things during an iteration: the features created
> by
> the iteration and the relationships that will sustain and support future
> iterations. If you "priority pack" (<- new phrase warning) each iteration,
> some significant percentage of the time you aren't going to deliver stuff
> the customer really wanted to see. That's bad for the relationship even if
> those iterations that go completely smoothly are good for the feature list.
>
> I think this is related to your recent quote about the Marine Corps. You
> want to create the habit of winning. You can't do that if you are
> frequently
> dropping stuff that really matters. As your estimates improve, you should
> be
> able to get away with less and less slack, but, as they say in
> manufacturing, any 100% utilized resource is a bottleneck.
>
> >
> > > I described slack at a workshop here in southern Oregon attended by
> > > Francesco Cirillo. Some people's initial reaction was very
> > negative--isn't
> > > this just sandbagging? Then Francesco said, "That's exactly
> > what we are
> > > doing right now. It's very important for us to deliver this
> > week, so we
> > > scheduled one tiny bit of new functionality and lots of
> > cleanup work."
> >
> > I'm not sure that's slack. A good choice of priorities, but is it
> > slack?
>
> It's slack because they deliberately scheduled less important items in
> order
> to improve the probability of delivery. They were running up to an
> important
> demo. If they delivered, all was well. If they didn't deliver the little
> bit
> of functionality they wanted to deliver in the iteration it would look
> really bad in the demo. Here's my assessment of the situation:
>
> Deliver Don't Deliver
> Feature +1 -1
> Relationship +10 -10
>
> That is, the one feature they picked would be nice for the demo but not
> critical. However, completing the iteration as committed was very valuable
> and not completing it was painful. In this case, lots of slack is the way
> to
> create the most value.
>
> Kent Beck
> Three Rivers Institute
>
> >
> > However, there could be an element of untruth in how one expresses
> > this notion. Sandbagging, as I understand it, occurs when I hold
> > back some of my capability without revealing it to the customer, so
> > that I have contingency resources left. We don't want that: we want
> > honesty. So we would like the team, customer plus developers, to
> > hold back some of /their/ capability, to provide contingency
> > resources.
> >
> > I feel that I'm standing at the edge of a slippery slope.
>
> Yes, and what keeps you from sliding down is integrity. If you treat your
> customer respectfully, keep them fully informed of your progress and of
> their options, and you do your best, then you don't have to fear the
> consequences.
>
> Kent Beck
> Three Rivers Institute
>
>
>
> Yahoo! Groups Sponsor
>
> ADVERTISEMENT
>
>
>
> ________________________________
> Yahoo! Groups Links
>
> To visit your group on the web, go to:
> http://groups.yahoo.com/group/xpbookdiscussiongroup/
>
> To unsubscribe from this group, send an email to:
> xpbookdiscussiongroup-unsubscribe-***@public.gmane.org
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


--
Nigel Thorne
Extreme Programmer & Coach
www.nigelthorne.com

[Ron Jeffries]

On Tuesday, March 1, 2005, at 3:14:40 PM, Nigel Thorne wrote:

> I think I am starting to understand. Thanks Kent for helping clarify
> slack for us.

> I have another question. How do you explain slack to the customer?

> Assume you were starting a new project with a new team (so no trust is
> yet established with the customer). Do you just approach it as "We
> believe we can get 12 pair hours a week completed. I would like you to
> pick 8 pair hours of high priority stories and 4 pair hours of less
> important stories that we can drop in the event that any of the high
> priority functionality overruns our estimate." ?

> So I guess my question is... How do you explain it, and what reactions
> do you tend to get?

I'm still at an earlier point on the curve. It seems to me that the
expected return from 12 hours of important stories is greater than
the expected return from 8 hours of important and 4 hours of less
important ones. It seems to me that the strategy of scheduling all
important work dominates the schedule of scheduling only some
important work.

What am I missing?

Ron Jeffries
www.XProgramming.com
Don't confuse more exact with better. -- Brian Marick

[Steve Hayes]

Ron Jeffries wrote:

> On Tuesday, March 1, 2005, at 3:14:40 PM, Nigel Thorne wrote:
>
> > I think I am starting to understand. Thanks Kent for helping clarify
> > slack for us.
>
> > I have another question. How do you explain slack to the customer?
>
> > Assume you were starting a new project with a new team (so no trust is
> > yet established with the customer). Do you just approach it as "We
> > believe we can get 12 pair hours a week completed. I would like you to
> > pick 8 pair hours of high priority stories and 4 pair hours of less
> > important stories that we can drop in the event that any of the high
> > priority functionality overruns our estimate." ?
>
> > So I guess my question is... How do you explain it, and what reactions
> > do you tend to get?
>
> I'm still at an earlier point on the curve. It seems to me that the
> expected return from 12 hours of important stories is greater than
> the expected return from 8 hours of important and 4 hours of less
> important ones. It seems to me that the strategy of scheduling all
> important work dominates the schedule of scheduling only some
> important work.
>
> What am I missing?
>
What I hear you saying is that the succcess of an iteration is measured
by the quantity of delivered software. What I hear Kent saying is that
the success of an iteration is measured by a function of the quantity of
delivered software AND the confidence the customer has in the
development team.

If we cram every iteration, and sometimes don't deliver what was
expected, the outcome may be inferior to leaving slack in each iteration
and meeting expectations every time. If the buffer is "important"
stories, no matter what we say about slack, the customer will feel
disappointed if we don't deliver them, so we fill the buffer with "less
important" stories, to minimise the disappointment. This also makes the
delivery of "important" stories more predictable, as they don't slip
back and forth between iterations as slack is available/consumed.

Does that make any sense?

Steve Hayes

[Ron Jeffries]

On Tuesday, March 1, 2005, at 9:55:50 PM, Steve Hayes wrote:

>> I'm still at an earlier point on the curve. It seems to me that the
>> expected return from 12 hours of important stories is greater than
>> the expected return from 8 hours of important and 4 hours of less
>> important ones. It seems to me that the strategy of scheduling all
>> important work dominates the schedule of scheduling only some
>> important work.
>>
>> What am I missing?
>>
> What I hear you saying is that the succcess of an iteration is measured
> by the quantity of delivered software. What I hear Kent saying is that
> the success of an iteration is measured by a function of the quantity of
> delivered software AND the confidence the customer has in the
> development team.

> If we cram every iteration, and sometimes don't deliver what was
> expected, the outcome may be inferior to leaving slack in each iteration
> and meeting expectations every time. If the buffer is "important"
> stories, no matter what we say about slack, the customer will feel
> disappointed if we don't deliver them, so we fill the buffer with "less
> important" stories, to minimise the disappointment. This also makes the
> delivery of "important" stories more predictable, as they don't slip
> back and forth between iterations as slack is available/consumed.

> Does that make any sense?

Yes. But ...

1) Not getting something I didn't really want might in some sense
be better than not getting something I did want, but

2) Not getting to even ASK for something I want, instead being
required to ask for something I want less, in hopes that I'll be
disappointed less when I don't get it, seems ... odd, and

3) I wonder what happened to playing to win instead of not to
lose.

I'm just not getting it, I guess.

Ron Jeffries
www.XProgramming.com
To be on the wire is life. The rest is waiting. --Karl Wallenda

[Steve Hayes]

Ron Jeffries wrote:

> On Tuesday, March 1, 2005, at 9:55:50 PM, Steve Hayes wrote:
>
> >> I'm still at an earlier point on the curve. It seems to me that the
> >> expected return from 12 hours of important stories is greater than
> >> the expected return from 8 hours of important and 4 hours of less
> >> important ones. It seems to me that the strategy of scheduling all
> >> important work dominates the schedule of scheduling only some
> >> important work.
> >>
> >> What am I missing?
> >>
> > What I hear you saying is that the succcess of an iteration is measured
> > by the quantity of delivered software. What I hear Kent saying is that
> > the success of an iteration is measured by a function of the quantity of
> > delivered software AND the confidence the customer has in the
> > development team.
>
> > If we cram every iteration, and sometimes don't deliver what was
> > expected, the outcome may be inferior to leaving slack in each iteration
> > and meeting expectations every time. If the buffer is "important"
> > stories, no matter what we say about slack, the customer will feel
> > disappointed if we don't deliver them, so we fill the buffer with "less
> > important" stories, to minimise the disappointment. This also makes the
> > delivery of "important" stories more predictable, as they don't slip
> > back and forth between iterations as slack is available/consumed.
>
> > Does that make any sense?
>
> Yes. But ...
>
> 1) Not getting something I didn't really want might in some sense
> be better than not getting something I did want, but
>
> 2) Not getting to even ASK for something I want, instead being
> required to ask for something I want less, in hopes that I'll be
> disappointed less when I don't get it, seems ... odd, and
>
> 3) I wonder what happened to playing to win instead of not to
> lose.
>
> I'm just not getting it, I guess.
>
(3) gave me pause. I've worked with customers where what you (Ron) is
suggested worked entirely well - we could happily say that we might or
might not get some important thing done this iteration, and please pick
the thing that you want least (out of all the important things). No
recriminations if we didn't get it done.

My current (external) customer doesn't work like that. They're
scheduling external (outside the team) resources for testing at the end
of each *iteration* (not at the end of a release). In this world, if we
*might* not deliver something at the end of the iteration, we may as
well not deliver it, since there won't be anyone scheduled to look at it
anyway.

But I admit that I'm back to square one, and I probably need to read the
thread all over again, this time paying attention.

Steve

[Gary Brown]

Steve Hayes wrote:

>
>
> Ron Jeffries wrote:
>
> > On Tuesday, March 1, 2005, at 9:55:50 PM, Steve Hayes wrote:
> >
> > >> I'm still at an earlier point on the curve. It seems to me that the
> > >> expected return from 12 hours of important stories is greater than
> > >> the expected return from 8 hours of important and 4 hours of less
> > >> important ones. It seems to me that the strategy of scheduling all
> > >> important work dominates the schedule of scheduling only some
> > >> important work.
> > >>
> > >> What am I missing?
> > >>
> > > What I hear you saying is that the succcess of an iteration is
> measured
> > > by the quantity of delivered software. What I hear Kent saying is that
> > > the success of an iteration is measured by a function of the
> quantity of
> > > delivered software AND the confidence the customer has in the
> > > development team.
> >
> > > If we cram every iteration, and sometimes don't deliver what was
> > > expected, the outcome may be inferior to leaving slack in each
> iteration
> > > and meeting expectations every time. If the buffer is "important"
> > > stories, no matter what we say about slack, the customer will feel
> > > disappointed if we don't deliver them, so we fill the buffer with
> "less
> > > important" stories, to minimise the disappointment. This also
> makes the
> > > delivery of "important" stories more predictable, as they don't slip
> > > back and forth between iterations as slack is available/consumed.
> >
> > > Does that make any sense?
> >
> > Yes. But ...
> >
> > 1) Not getting something I didn't really want might in some sense
> > be better than not getting something I did want, but
> >
> > 2) Not getting to even ASK for something I want, instead being
> > required to ask for something I want less, in hopes that I'll be
> > disappointed less when I don't get it, seems ... odd, and
> >
> > 3) I wonder what happened to playing to win instead of not to
> > lose.
> >
> > I'm just not getting it, I guess.
> >
> (3) gave me pause. I've worked with customers where what you (Ron) is
> suggested worked entirely well - we could happily say that we might or
> might not get some important thing done this iteration, and please pick
> the thing that you want least (out of all the important things). No
> recriminations if we didn't get it done.
>
> My current (external) customer doesn't work like that. They're
> scheduling external (outside the team) resources for testing at the end
> of each *iteration* (not at the end of a release). In this world, if we
> *might* not deliver something at the end of the iteration, we may as
> well not deliver it, since there won't be anyone scheduled to look at it
> anyway.

Steve,

I am dealing with this problem on one of my teams right now. This team
is reimplementing an existing system. They know all of the good parts
and all of the warts. They want to keep all of the good stuff and
improve all of the bad. For any given story, there are literally
hundreds of things that we could do. What I am asking them to do is to
design each new feature end to end, adding only the minimum amount of
functionality needed to deliver the new requirement. This is harder
than it looks. It is easier to say than it is to do. They often want
to add things that are nice to have, but are not immediately required.
The impact on velocity is huge.

We have a story, we give an estimate. That story is our invitation to
communicate with the customer to understand what needs to be done. It
is also our commitment to deliver. When we accept that story in the
current iteration, we promise to deliver. Obviously, sometimes stuff
happens. We're not going to be perfect. But we need to do our best to
deliver on our promises. We need to be responsible and accountable.
Sometimes, we need to put in a little overtime to get things done. That
is where trust and respect come from.

GB.

[William Pietri]

On Wed, 2005-03-02 at 14:55 +1100, Steve Hayes wrote:
> If we cram every iteration, and sometimes don't deliver what was
> expected, the outcome may be inferior to leaving slack in each
> iteration and meeting expectations every time. If the buffer is
> "important" stories, no matter what we say about slack, the customer
> will feel disappointed if we don't deliver them, so we fill the buffer
> with "less important" stories, to minimise the disappointment.

I could be persuaded that for most teams, it's better to set achievable
goals every week. Certainly that's my habit. But I don't yet see the
value in scheduling low-value stories with the expectation that we'll
probably cut some of them.

My general strategy to get slack is to schedule conservatively. Every
week, we consider both Yesterday's Weather and what we guess the team
can achieve. Then we schedule based on the lower of those two numbers.
This means we're pretty likely to make our goal.

If we get to the end of the week and have more time, we might pull up
stories or we might do some techie thing, like cleanup, research, or
training. Either way, we all feel like we've won, because we've done
what we planned and a little more. To me, that seems like a better
outcome than consoling ourselves with the fact that the things we didn't
get done weren't really that important.


William

--
William Pietri <william-***@public.gmane.org>

[Tim King]

Ron Jeffries wrote:
> It seems to me that the
> expected return from 12 hours of important stories is greater than
> the expected return from 8 hours of important and 4 hours of less
> important ones.

Hi, Ron. I don't understand. Isn't that a little like saying a pound of
feathers weighs less than a pound of bricks?

> It seems to me that the strategy of scheduling all
> important work dominates the schedule of scheduling only some
> important work.

Could you put that another way? (How can a strategy dominate a schedule?
What is a "schedule of scheduling"?)

> What am I missing?

I myself am most comfortable scheduling all the most important stories
up-front, if that's what you're saying. A more important story should in
general take priority over a less-important one. That will mean that
important stories scheduled for this iteration _will_ get dropped. I
know some stakeholders can't handle that, so the issue must be finessed.
I've been in situations in which I had to try a couple times before
settling on a set of rules that allowed maximum bang for the buck
without people thinking I was unreliable and undependable.

Still, my preference is, in order:

1. Schedule all the most important stories, knowing that the last
N stories may not make it into the iteration.

2. If developers or other stakeholders can't handle #1, schedule all
the most important stories, specifically classifying the last N
stories as slack.

3. If stakeholders can't handle #2, schedule all the most important
stories inside the team, but only publish a schedule that commits
to as many stories as you know you can commit to.

4. If developers or other stakeholders can't handle #3, schedule as
many important stories as you can, but add N unimportant stories
specifically classifying them as slack.

5. ??? How low can you go?

What are your experiences?

-TimK
--
J. Timothy King ..team-oriented..object-oriented..Agile..
www.jtse.com ..C++..Perl..Java..assembly..embedded.systems..

[Jason Nocks]

On Tuesday 01 March 2005 11:13 pm, Tim King wrote:
> Ron Jeffries wrote:
> > It seems to me that the
> > expected return from 12 hours of important stories is greater than
> > the expected return from 8 hours of important and 4 hours of less
> > important ones.
>
> Hi, Ron. I don't understand. Isn't that a little like saying a pound of
> feathers weighs less than a pound of bricks?

Seems to me that Ron is saying something more like 12 bricks weigh more than 8
bricks plus 4 feathers.

> > It seems to me that the strategy of scheduling all
> > important work dominates the schedule of scheduling only some
> > important work.
>
> Could you put that another way? (How can a strategy dominate a schedule?
> What is a "schedule of scheduling"?)
>
> > What am I missing?
>
> I myself am most comfortable scheduling all the most important stories
> up-front, if that's what you're saying. A more important story should in
> general take priority over a less-important one. That will mean that
> important stories scheduled for this iteration _will_ get dropped. I
> know some stakeholders can't handle that, so the issue must be finessed.
> I've been in situations in which I had to try a couple times before
> settling on a set of rules that allowed maximum bang for the buck
> without people thinking I was unreliable and undependable.
>
> Still, my preference is, in order:
>
> 1. Schedule all the most important stories, knowing that the last
> N stories may not make it into the iteration.
>
> 2. If developers or other stakeholders can't handle #1, schedule all
> the most important stories, specifically classifying the last N
> stories as slack.
>
> 3. If stakeholders can't handle #2, schedule all the most important
> stories inside the team, but only publish a schedule that commits
> to as many stories as you know you can commit to.
>
> 4. If developers or other stakeholders can't handle #3, schedule as
> many important stories as you can, but add N unimportant stories
> specifically classifying them as slack.
>
> 5. ??? How low can you go?

I like this "fallback" approach better than going straight to #4 as well. It's
not clear to me whether anyone is recommending starting with #4.

#1 definitely seems to me to be the simplest of the above. I'd be wary of #3
though. I'd rather deal with the difference in expectations than work around
it. If that didn't work, I'd probably just skip #3 and go straight to #4.

> What are your experiences?

If the stakeholders insist on stories we can guarantee will be completed with
100% certainty, I'd be inclined to refer them to the previous iteration
(which has already been completed).

I think the issue gets a bit more hairy when we are doing a release plan
covering several iterations, particularly prior to completing a single
iteration. I feel much more confident after completing an iteration or two. I
suspect that the stakeholders do as well.

> -TimK

Cheers,
Jason Nocks

[Ron Jeffries]

On Tuesday, March 1, 2005, at 10:51:37 PM, Jason Nocks wrote:

> If the stakeholders insist on stories we can guarantee will be completed with
> 100% certainty, I'd be inclined to refer them to the previous iteration
> (which has already been completed).

Yes. I'd add that if the stakeholders are insisting on guarantees,
the problem isn't with what we are guaranteeing. It won't help to
guarantee 8 things they want and 4 things they don't care about. The
relationship ... the communications ... are broken.

Here's something to consider: produce an iteration plan showing a
gradation of certainty: 50% chance we'll get these 12, 75% these 9,
90% these 8.

No ... I'll leave that there on the remote chance that it's a good
idea. The good idea is that we need to sit down with the
stakeholders and lay our cards on the table and explain to them what
we know and what we don't, and then ask them how they would like to
have us present that information. So long as they are saying "you
have to know more than you can know", the conversation isn't over.

> I think the issue gets a bit more hairy when we are doing a release plan
> covering several iterations, particularly prior to completing a single
> iteration. I feel much more confident after completing an iteration or two. I
> suspect that the stakeholders do as well.

Yes. Even then, the velocity line should be seen as a cone, not a
line. It reaches up above its current slope, because we might speed
up.


I am still not seeing the case for scheduling unimportant stories.
To me it sounds like "Here's an idea. Let's promise you something
you hate ... maybe a root canal. Then when we fall short, you'll be
happy."

But I respect Kent and the other folks who are offering this idea. I
could be wrong, and just not getting it. I am not a professional
psychologist.

Ron Jeffries
www.XProgramming.com
The main reason that testing at the end of a development cycle finds
problems is not that problems were put in near the end, it is that
testing was put off until then.

[Ron Jeffries]

On Wednesday, March 2, 2005, at 5:15:40 AM, Ron Jeffries wrote:

> Yes. Even then, the velocity line should be seen as a cone, not a
> line. It reaches up above its current slope, because we might speed
> up.

Oops, snipped "And it reaches down below its current slope, because
we might slow down."

Ron Jeffries
www.XProgramming.com
I could be wrong. I frequently am.

[BenAveling]

Jason Nocks wrote:

>Seems to me that Ron is saying something more like 12 bricks weigh more than 8
>bricks plus 4 feathers.
>
>

Seems to me that Ron is saying that 12 grams of gold might be worth more
than 8 grams of gold plus 4 grams of silver.

Regards, Ben A.

[Ron Jeffries]

I've hammered on this enough. But both these analogies have
something to offer and I like them:

On Wednesday, March 2, 2005, at 5:17:09 AM, BenAveling wrote:

> Jason Nocks wrote:

>>Seems to me that Ron is saying something more like 12 bricks weigh more than 8
>>bricks plus 4 feathers.

This one is quite evocative, and I like it for that reason.

> Seems to me that Ron is saying that 12 grams of gold might be worth more
> than 8 grams of gold plus 4 grams of silver.

This one is very accurate, and I like it for that reason.

Ron Jeffries
www.XProgramming.com
Speak the affirmative; emphasize your choice
by utterly ignoring all that you reject. -- Ralph Waldo Emerson

[William E Caputo]

Ron:
>> Seems to me that Ron is saying that 12 grams of gold might be worth
more
>> than 8 grams of gold plus 4 grams of silver.

>This one is very accurate, and I like it for that reason.

This thread is looking a bit winded, but I thought I'd use this metaphor
to point something out:

Assuming all coins are equal in effort, if we schedule 12 coins of work
and only do 10:
In scenario 1 (12 gold scheduled) we get 10 gold worth of work done.
In scenario 2 (8 gold 4 silver) we get 8 gold and 2 silver done (i.e. less
value delivered).

*However* in each scenario what we failed to live up to (i.e. perceived
loss) was:
Scenario 1: 2 gold
Scenario 2: 2 silver

Since expectations are managed on how closely we live up to delivering on
what we promise rather than on the quantity of how much we deliver,
Scenario 2 will more closely meet expectations and so will have a smaller
impact on our customer's confidence in our estimates.

Ron, you pointed out somewhere on your blog (I can't find it now) that
there is an irregular distribution around zero with regard to expectations
(i.e. we don't react the same when something is favorably unexpected as
when its unfavorably unexpected). Whether its logical or not, not getting
two silver sounds better than not getting two gold -- regardless of how
much we actually did get.

Thus, I understand this application of slack as a way of building
long-term trust in our ability to deliver (and thus increasing our overall
capability to deliver value), not about maximizing short-term delivery of
value (which may lead to relatively low total value delivered, if our
customer perceives that we can't deliver what we promise).

In short (and to mingle threads) we value building trust and delivering
the most value, this application of slack seeks long-term balance between
them.

Best,
Bill

William E. Caputo
ThoughtWorks, Inc.
http://www.williamcaputo.com
--------
Never get so caught up in cutting wood that you forget to sharpen your ax.

[Ron Jeffries]

On Wednesday, March 2, 2005, at 12:53:02 PM, William E Caputo wrote:

> Assuming all coins are equal in effort, if we schedule 12 coins of work
> and only do 10:
> In scenario 1 (12 gold scheduled) we get 10 gold worth of work done.
> In scenario 2 (8 gold 4 silver) we get 8 gold and 2 silver done (i.e. less
> value delivered).

> *However* in each scenario what we failed to live up to (i.e. perceived
> loss) was:
> Scenario 1: 2 gold
> Scenario 2: 2 silver

> Since expectations are managed on how closely we live up to delivering on
> what we promise rather than on the quantity of how much we deliver,
> Scenario 2 will more closely meet expectations and so will have a smaller
> impact on our customer's confidence in our estimates.

> Ron, you pointed out somewhere on your blog (I can't find it now) that
> there is an irregular distribution around zero with regard to expectations
> (i.e. we don't react the same when something is favorably unexpected as
> when its unfavorably unexpected). Whether its logical or not, not getting
> two silver sounds better than not getting two gold -- regardless of how
> much we actually did get.

> Thus, I understand this application of slack as a way of building
> long-term trust in our ability to deliver (and thus increasing our overall
> capability to deliver value), not about maximizing short-term delivery of
> value (which may lead to relatively low total value delivered, if our
> customer perceives that we can't deliver what we promise).

> In short (and to mingle threads) we value building trust and delivering
> the most value, this application of slack seeks long-term balance between
> them.

I believe that I understand the reasoning. However, it would make
even more sense to schedule the 8 gold we are sure of, and nothing
else, thus ensuring that our possible loss is zero. Then, should we
have time left over, we could ask for another story. The result
would be that every promise would be kept, and all surprises would
be happy ones.

I believe that the best strategy is always to deliver the next most
valuable story, and that it would take some very unusual settings of
perceived utility, or trust building, to make choosing inferior
stories a better strategy than choosing superior stories.

More important, I have this nagging feeling that fiddling the
promise borders on manipulation or trickery, and that what's more
likely called for is better communication.

One last thing: I've been lucky enough never to encounter a customer
whose promise orientation was so strong as to push me toward this
kind of solution. Could just be luck, I guess.

Ron Jeffries
www.XProgramming.com
Keep away from people who try to belittle your ambitions. Small people
always do that, but the really great make you feel that you, too, can
become great." -- Mark Twain.

[Kent Beck]

Ben,

Something that bothers me about this whole discussion is people's apparent
need to wring every last iota of value out of development. If the company
really is going to fold if you get widget X done on Tuesday instead of
Monday, you already have bigger problems than can be solved by programming.
Most of the time while what we're doing is valuable, it just isn't that
important. That's not an excuse not to do our best, but packing schedules so
they look more impressive and risking a weekly disintegration of our
relationship to our customers doesn't make sense. Why not commit to what we
can commit to and separate that from our wish list. If we are better than we
actually are, there is nothing to stop us from hitting the wish list.

Kent Beck
Three Rivers Institute

> -----Original Message-----
> From: BenAveling [mailto:bena-***@public.gmane.org]
> Sent: Wednesday, March 02, 2005 3:17 AM
> To: xpbookdiscussiongroup-***@public.gmane.org
> Subject: Re: [xpe2e] Planning game confusion
>
>
>
> Jason Nocks wrote:
>
> >Seems to me that Ron is saying something more like 12 bricks
> weigh more than 8
> >bricks plus 4 feathers.
> >
> >
>
> Seems to me that Ron is saying that 12 grams of gold might be
> worth more
> than 8 grams of gold plus 4 grams of silver.
>
> Regards, Ben A.

[Tim King]

Jason Nocks wrote:
> If the stakeholders insist on stories we can guarantee will be completed with
> 100% certainty, I'd be inclined to refer them to the previous iteration
> (which has already been completed).

This is a good point, but it may come off as flippant. If they were
willing to hold their plans until stories were complete, they wouldn't
be so concerned with commitments in the current iteration.

Customers (and other stakeholders) can be funny sometimes. Ideally,
everything works perfectly, the first time, on time, without any cost.
Of course, everyone knows this ideal doesn't exist, but sometimes we
need to recite the mantra a few times before it really starts to sink
in: The only thing we can truly count on is that the unexpected will happen.

-TimK
--
J. Timothy King ..team-oriented..object-oriented..Agile..
www.jtse.com ..C++..Perl..Java..assembly..embedded.systems..

[Ron Jeffries]

On Wednesday, March 2, 2005, at 8:58:02 AM, Tim King wrote:

> Customers (and other stakeholders) can be funny sometimes. Ideally,
> everything works perfectly, the first time, on time, without any cost.
> Of course, everyone knows this ideal doesn't exist, but sometimes we
> need to recite the mantra a few times before it really starts to sink
> in: The only thing we can truly count on is that the unexpected will happen.

What is fascinating is that there is no aspect of life or business
where things work perfectly, the first time, on time, without any
cost. And yet they ask us for that. I believe that it is because,
historically, they've had no way to steer, so they don't recognize
right away that now they have one.

Ron Jeffries
www.XProgramming.com
Only the hand that erases can write the true thing. -- Meister Eckhart

[Ron Jeffries]

On Tuesday, March 1, 2005, at 10:13:34 PM, Tim King wrote:

>> It seems to me that the strategy of scheduling all
>> important work dominates the schedule of scheduling only some
>> important work.

> Could you put that another way? (How can a strategy dominate a schedule?
> What is a "schedule of scheduling"?)

It seems to me that the strategy of scheduling all important work
dominates the STRATEGY of scheduling only some important work.

Ron Jeffries
www.XProgramming.com
Improvement stops when we start believing that
ideas about how to improve are insulting.

[Dale Emery]

Hi Tim and all,

Here's a scheduling idea I just made up:

Schedule the highest priority stories for the iteration. If you
have, say, a 3 point story scheduled for the end of the
iteration, then identify the most valuable 2 point story and 1
point story that haven't been scheduled. As you approach the end
of the iteration, if you have time for the 3 point story, do it.
Otherwise do the 2 pointer or the 1 pointer, whichever is the
most valuable story you have time for.

The idea is to always know the most valuable story you can do in
the remaining time.

Dale

--
Dale Emery, Consultant
Inspiring Leadership for Software People
Web: http://www.dhemery.com
Weblog: http://www.dhemery.com/cwd

They didn't release that film. It escaped. --Samuel Goldwyn

[Ron Jeffries]

On Wednesday, March 2, 2005, at 6:36:11 AM, Dale Emery wrote:

> Here's a scheduling idea I just made up:

> Schedule the highest priority stories for the iteration. If you
> have, say, a 3 point story scheduled for the end of the
> iteration, then identify the most valuable 2 point story and 1
> point story that haven't been scheduled. As you approach the end
> of the iteration, if you have time for the 3 point story, do it.
> Otherwise do the 2 pointer or the 1 pointer, whichever is the
> most valuable story you have time for.

> The idea is to always know the most valuable story you can do in
> the remaining time.

Interesting! Also points to the value of tiny stories.

Ron Jeffries
www.XProgramming.com
Any errors you find in this are the work of Secret Villains,
whose mad schemes will soon be revealed. -- Wil McCarthy

[Steve Bate]

> From: Dale Emery [mailto:dale-***@public.gmane.org]
> Here's a scheduling idea I just made up:
>
> Schedule the highest priority stories for the iteration. If you
> have, say, a 3 point story scheduled for the end of the
> iteration, then identify the most valuable 2 point story and 1
> point story that haven't been scheduled. As you approach the end
> of the iteration, if you have time for the 3 point story, do it.
> Otherwise do the 2 pointer or the 1 pointer, whichever is the
> most valuable story you have time for.
>
> The idea is to always know the most valuable story you can do in
> the remaining time.

Hi Dale,

I've been on teams that used approaches similar to this and it
works well. The team I'm thinking of deployed frequently so there
was no long term release plan. We maintained a work queue and our
planning had a 1-2 iteration time horizon. I'm wondering how your
technique would affect a team with long term release plans given
the release and iteration plans could potentially change
frequently. Also, when you say a team decides it has time for a
3 point story, I'm not sure if you are assuming that effort points
are a some function of time rather than abstract units (e.g. high,
low, medium difficulty)? In the latter case, a team wouldn't know
how much time an X point story would require. The team I mentioned
earlier used programming time (ideal time) estimates so that wasn't
a significant issue for us (assuming consistent overhead).

Steve

[Dale Emery]

Hi Steve,

> Also, when you say a team decides it has time for a 3 point
> story, I'm not sure if you are assuming that effort points are
> a some function of time rather than abstract units (e.g. high,
> low, medium difficulty)?

Yes I was assuming that. If that assumption doesn't hold true,
the team will have to adjust in some way.

The theme is: How can we always know the highest priority story
that we have time to do? Actually, two words here are too
strong: "know" is too strong. We are, after all, talking about
estimates. And "always" is too string. It would probably be
enough that the team can quickly find out the highest priority 2
point or 1 point story, such as by asking the Customer.

I just noticed that I'm also assuming that there are no
dependencies between stories. If there are dependencies, then
the algorithm probably becomes awkward.

Dale

--
Dale Emery, Consultant
Inspiring Leadership for Software People
Web: http://www.dhemery.com
Weblog: http://www.dhemery.com/cwd

That's not an optical illusion; it just looks like one. --Dale Emery

[Steve Bate]

> From: Dale Emery [mailto:dale-***@public.gmane.org]
> ...
> The theme is: How can we always know the highest priority story
> that we have time to do? Actually, two words here are too
> strong: "know" is too strong. We are, after all, talking about
> estimates. And "always" is too string. It would probably be
> enough that the team can quickly find out the highest priority 2
> point or 1 point story, such as by asking the Customer.

Makes sense to me.

> I just noticed that I'm also assuming that there are no
> dependencies between stories. If there are dependencies, then
> the algorithm probably becomes awkward.

Good point. If stories are decomposed to the point where there
are multiple stories for a specific business feature, the
chances for dependency issues might be greater.

[Tim King]

Dale Emery wrote:
> Schedule the highest priority stories for the iteration. If you
> have, say, a 3 point story scheduled for the end of the
> iteration, then identify the most valuable 2 point story and 1
> point story that haven't been scheduled. As you approach the end
> of the iteration, if you have time for the 3 point story, do it.
> Otherwise do the 2 pointer or the 1 pointer, whichever is the
> most valuable story you have time for.

This is a neat idea which I will try. I like it because you can complete
stories that are important but manageable. As a developer, I can have a
sense of accomplishment in finishing the smaller story, rather than the
feeling of knowing a partially-finished story is waiting for me over the
weekend. Knowing that you can accomplish the complete story in this
iteration also can further energize the work.

We still can't commit to any of these stories, and somehow the customer
has to understand that. But at least any extras we deliver will be the
best we can muster.

-TimK
--
J. Timothy King ..team-oriented..object-oriented..Agile..
www.jtse.com ..C++..Perl..Java..assembly..embedded.systems..

[Kent Beck]

Tim,

What will you do if you can't force the customer to understand? How about
having a list of commitments and a wish list you could chose from if you are
quicker and cleverer than you think you are? Could your customers understand
that?

Kent Beck
Three Rivers Institute

> -----Original Message-----
> From: Tim King [mailto:timk-***@public.gmane.org]
> Sent: Wednesday, March 02, 2005 7:10 AM
> To: xpbookdiscussiongroup-***@public.gmane.org
> Subject: Re: [xpe2e] Planning game confusion
>
> This is a neat idea which I will try. I like it because you
> can complete
> stories that are important but manageable. As a developer, I
> can have a
> sense of accomplishment in finishing the smaller story,
> rather than the
> feeling of knowing a partially-finished story is waiting for
> me over the
> weekend. Knowing that you can accomplish the complete story in this
> iteration also can further energize the work.
>
> We still can't commit to any of these stories, and somehow
> the customer
> has to understand that. But at least any extras we deliver
> will be the
> best we can muster.

[Jim Shore]

Ron Jeffries wrote:
> I'm still at an earlier point on the curve. It seems to me that the
> expected return from 12 hours of important stories is greater than
> the expected return from 8 hours of important and 4 hours of less
> important ones. It seems to me that the strategy of scheduling all
> important work dominates the schedule of scheduling only some
> important work.
>
> What am I missing?

I use an alternate approach. I agree that slack is important, and I
also agree that not scheduling the most valuable stories seems somehow
wrong. Besides, you're still scheduling stories and potentially not
doing them. That doesn't feel like slack to me.

With my teams, I recommend scheduling half a day of "research time" --
an idea I stole from John Brewer -- every week. This research time is
open time for looking into new ideas and technology: anything not
related to scheduled tasks, in fact. I've found research time to be
very valuable, leading to returns much sooner than I expected.
Typically within a month, in fact.

Research time is /valuable/ but not /essential/. It plays the role of
slack very well. We can always use some of it if we're having trouble
completing an iteration. If we found ourselves using it every
iteration, then obviously we're pushing too hard on our estimates.

Jim

--
James Shore - Titanium I.T. LLC

Upcoming presentation, March 10th, Portland Ore.:
"Beyond Story Cards: Agile Requirements Collaboration"
For free registration, visit http://tinyurl.com/6p2ko

phone: [phone]
email: jshore-***@public.gmane.org
web/blog: http://www.jamesshore.com

[Tim King]

Jim Shore wrote:
> With my teams, I recommend scheduling half a day of "research time" --
> an idea I stole from John Brewer -- every week...
> Research time is /valuable/ but not /essential/. It plays the role of
> slack very well. We can always use some of it if we're having trouble
> completing an iteration. If we found ourselves using it every
> iteration, then obviously we're pushing too hard on our estimates.

That's interesting. I tend to treat research time as separate from
slack. Actually, I tend to treat slack as separate from slack. Let me
explain.

What I got from Kent's slack is a replacement for schedule padding.
Padding out each iteration's schedule, especially with small iterations,
is wasteful. But at the same time, you want to be able to commit to
deliverables and to show solid progress in each iteration, keeping the
iterations short. We wrestle with these forces each time we plan an
iteration.

There's another kind of slack, the time we spend making the right
choices. Creativity happens in the slack. I've always put research time
into this category. In this sense, research time is like the 40-hour
work week. We can work a little more occasionally, but over the long
term, it /is/ essential. I set aside time each week to make sure I'm
informed, just as I give myself enough time to understand what I'm
designing before I design it.

Directed research frequently is part of development, too. If we need to
solve a particular problem and we know of a technology that may help, we
implement a spike solution using that technology. That's research. It
also commonly goes on a story card. Of course, before we can even know
of that technology, we will need to have read about it. So non-directed
research time pays off in directed research and development.

-TimK
--
J. Timothy King ..team-oriented..object-oriented..Agile..
www.jtse.com ..C++..Perl..Java..assembly..embedded.systems..

[b***@public.gmane.org]

> Assuming all coins are equal in effort, if we schedule 12 coins of work
> and only do 10:
> In scenario 1 (12 gold scheduled) we get 10 gold worth of work done.
> In scenario 2 (8 gold 4 silver) we get 8 gold and 2 silver done (i.e.
less
> value delivered).

> *However* in each scenario what we failed to live up to (i.e. perceived
> loss) was:
> Scenario 1: 2 gold
> Scenario 2: 2 silver

Scenario 3

Scheduled: 8 gold + 4 silver
Delivered: 6 gold + 4 silver
Shortfall: 2 gold.

Regards, Ben

This email may contain privileged/confidential information. You may not copy or disclose this email to anyone without the written permission of the sender. If you have received this email in error please kindly delete this message and notify the sender. Opinions expressed in this email are those of the sender and not necessarily the opinions of the employer.

This email and any attached files should be scanned to detect viruses. No liability will be accepted by the employer for loss or damage (whether caused by negligence or not) as a result of email transmission.

[William E Caputo]

Ben:
>Scenario 3
>Scheduled: 8 gold + 4 silver
>Delivered: 6 gold + 4 silver
>Shortfall: 2 gold.

I don't see how this scenario follows from Ron's questioning of the slack
question. It sems to either violate the premise: "Assuming all coins are
of equal effort" or the (at least how I heard Ron saying) earlier implied
premise: "The team values delivering the highest value stories first."

In both of the prior two scenarios, this implied premise is maintained --
in fact this whole discussion could be recast as asking: Should we value
long-term trust building over short-term delivery of highest value as a
strategy to maximize long-term delivery of highest value? I heard Kent say
"Yes" I heard Ron say "I don't know if I buy that."

Scenario 3 seems to achieve neither of those goals (and violates one or
both premises). So maybe now I am missing something?

Best,
Bill

William E. Caputo
ThoughtWorks, Inc.
http://www.williamcaputo.com
--------
Never get so caught up in cutting wood that you forget to sharpen your ax.

[b***@public.gmane.org]

Hi William,

My point is that you can't always control where slippage happens.
Sometimes the higher valued stories are the ones that slip.

I'd rather put the highest value stories, and fail to deliver, than
deliberately put in stuff that no-one really cares about, even if I
succeed.

Maybe the answer is change the language slightly. Even an estimate can
set expectations. If we estimate based on the average then we are going
to fall short of expectations about half the time. That's not good for
anyone.

Suppose that experience tells us we are confident of doing 10 coins, can
expect to do 12 on average, and that we do 14 coins or more at least as
often as we do 10 or less.

We then commit to deliver 10 gold coins this iteration, and promise to try
to bring forwards 2 to 4 gold coins from the next iteration as well.

Would that be attractive to the customer? Would they believe that we can
do it? Would they believe that we are going to genuinely try to do it?

If the answer to the first question is no, we need to aim higher.

If the answer to the second or third questions are no, we need to aim
lower.

If the answer to all three questions are no, we have a serious problem,
but it's not necessarily a communications problem.

>Should we value long-term trust building over short-term delivery of
highest value
>as a strategy to maximize long-term delivery of highest value?

We value both. Usually, there are trade-offs, but they aren't
diametrically opposed to each other.

If short and long term are badly in conflict, we have to decide if there
is mutual value in a short term relationship that might turn into a long
term relationship.

Remember that the customer is just like us: they want the maximum return
for the minimum cost, everything else being equal. Getting everything for
nothing would be nice but they are prepared to settle for less than that
or they wouldn't have hired us.

>Scenario 3 seems to achieve neither of those goals

Scenario 3 was intended as a worst case outcome. Sorry not to make that
clearer.

Regards, Ben





William E Caputo <wecaputo-***@public.gmane.org>
03/03/2005 11:25
Please respond to xpbookdiscussiongroup

To: xpbookdiscussiongroup-***@public.gmane.org
cc:
Subject: Re: Fw: [xpe2e] Planning game confusion



Ben:
>Scenario 3
>Scheduled: 8 gold + 4 silver
>Delivered: 6 gold + 4 silver
>Shortfall: 2 gold.

I don't see how this scenario follows from Ron's questioning of the slack
question. It sems to either violate the premise: "Assuming all coins are
of equal effort" or the (at least how I heard Ron saying) earlier implied
premise: "The team values delivering the highest value stories first."

In both of the prior two scenarios, this implied premise is maintained --
in fact this whole discussion could be recast as asking: Should we value
long-term trust building over short-term delivery of highest value as a
strategy to maximize long-term delivery of highest value? I heard Kent say

"Yes" I heard Ron say "I don't know if I buy that."

Scenario 3 seems to achieve neither of those goals (and violates one or
both premises). So maybe now I am missing something?

Best,
Bill

William E. Caputo
ThoughtWorks, Inc.
http://www.williamcaputo.com
--------
Never get so caught up in cutting wood that you forget to sharpen your ax.




Yahoo! Groups Links










This email may contain privileged/confidential information. You may not copy or disclose this email to anyone without the written permission of the sender. If you have received this email in error please kindly delete this message and notify the sender. Opinions expressed in this email are those of the sender and not necessarily the opinions of the employer.

This email and any attached files should be scanned to detect viruses. No liability will be accepted by the employer for loss or damage (whether caused by negligence or not) as a result of email transmission.

[J. B. Rainsberger]

bena-***@public.gmane.org wrote:

> I'd rather put the highest value stories, and fail to deliver, than
> deliberately put in stuff that no-one really cares about, even if I
> succeed.

If I were your customer, I would be much more concerned about how I feel
about your failure to deliver on your promise than I would be about how
you feel about it.

As I read all these messages in one session, I formed this impression
that many of us are perfectly all right with disbelieving the plan. I
think that's quite realistic of us. Still, I wonder how many of our
customers think quite so realistically. I have worked with one or two,
but not many. In most cases, customers still expect us to deliver what
we plan to deliver most of the time.
--
J. B. (Joe) Rainsberger
Diaspar Software Services
http://www.diasparsoftware.com
Author, JUnit Recipes: Practical Methods for Programmer Testing

[Ron Jeffries]

On Tuesday, March 15, 2005, at 3:57:11 PM, J. B. Rainsberger wrote:

> As I read all these messages in one session, I formed this impression
> that many of us are perfectly all right with disbelieving the plan. I
> think that's quite realistic of us. Still, I wonder how many of our
> customers think quite so realistically. I have worked with one or two,
> but not many. In most cases, customers still expect us to deliver what
> we plan to deliver most of the time.

Many do say that. But what is it in their lives that leads them to
believe that plans are usually met? I ask this because I believe
that their experience does not lead them to believe that ... and
that they express that expectation of perfection to us for another
reason than that they really expect it.

Ron Jeffries
www.XProgramming.com
Improvement stops when we start believing that
ideas about how to improve are insulting.

[William E Caputo]

Ron:

>Many do say that. But what is it in their lives that leads them to
>believe that plans are usually met?

What makes you believe that they actually believe us? What is it in your
life that leads you to believe that they really do? (and yes I'm being as
rhetorical as you).

But let's say they do believe that the plan will be met this time. Maybe
its the hope that this time its going to be different. Maybe they want to
trust us, and are extending it unearned this first time.

Maybe they apply their own 'Kentucky windage' and 'yesterday's weather'
and they intend to use past experience to do so. They have plans to make
too. But are we helping them plan effectively?

They can't if we overpromise and underdeliver, because they have open
downside risk (i.e. they don't know how much to adjust).
They can't if we promise honestly, but don't -- for whatever reason --
make good on it (same reason, plus both liars and truth tellers sound the
same when making excuses).
They *can* if we promise honestly and execute flawlessly -- but who can do
that?
They *can* if we underpromise and overdeliver, because their downside risk
is fixed at our word (i.e. they can use the same tactic with their plan).

Note that their capability to plan has *nothing* to do with our intent
(i.e. our character) only with what they expect, and what we deliver (i.e.
our competence).

This is why we can trust those who underpromise and overdeliver --
especially early on in a project -- even if we suspect that they might be
sandbagging a bit.

"Saying no we're the truth tellers, this is what we *really* believe."
Doesn't solve anything. Our actions are so loud, they can't hear what we
say. I value honesty -- and they might too, but they still won't want to
work with a team who simply stands by their honest estimates. They can
trust their character, but not their competence. Keep in mind too, that
opinion isn't fact, so there is no honesty in estimates except that we are
honestly opening up the floodgates of our internal emotions and
suppositions. I'd expect their response to me doing this would be: "I'm
your customer, not your shrink."

Best,
Bill

William E. Caputo
ThoughtWorks, Inc.
http://www.williamcaputo.com
--------
Never get so caught up in cutting wood that you forget to sharpen your ax.

[b***@public.gmane.org]

> Maybe they apply their own 'Kentucky windage' and 'yesterday's weather'
> and they intend to use past experience to do so. They have plans to make

> too. But are we helping them plan effectively?

> They can't if we overpromise and underdeliver, because they have open
> downside risk (i.e. they don't know how much to adjust).

What if they use yesterday's weather to assume that we have overpromised
and will under deliver by about as much as last time?

Regards, Ben





William E Caputo <wecaputo-***@public.gmane.org>
17/03/2005 03:41
Please respond to xpbookdiscussiongroup

To: xpbookdiscussiongroup-***@public.gmane.org
cc:
Subject: Re: Fw: [xpe2e] Planning game confusion



Ron:

>Many do say that. But what is it in their lives that leads them to
>believe that plans are usually met?

What makes you believe that they actually believe us? What is it in your
life that leads you to believe that they really do? (and yes I'm being as
rhetorical as you).

But let's say they do believe that the plan will be met this time. Maybe
its the hope that this time its going to be different. Maybe they want to
trust us, and are extending it unearned this first time.

Maybe they apply their own 'Kentucky windage' and 'yesterday's weather'
and they intend to use past experience to do so. They have plans to make
too. But are we helping them plan effectively?

They can't if we overpromise and underdeliver, because they have open
downside risk (i.e. they don't know how much to adjust).
They can't if we promise honestly, but don't -- for whatever reason --
make good on it (same reason, plus both liars and truth tellers sound the
same when making excuses).
They *can* if we promise honestly and execute flawlessly -- but who can do

that?
They *can* if we underpromise and overdeliver, because their downside risk

is fixed at our word (i.e. they can use the same tactic with their plan).

Note that their capability to plan has *nothing* to do with our intent
(i.e. our character) only with what they expect, and what we deliver (i.e.

our competence).

This is why we can trust those who underpromise and overdeliver --
especially early on in a project -- even if we suspect that they might be
sandbagging a bit.

"Saying no we're the truth tellers, this is what we *really* believe."
Doesn't solve anything. Our actions are so loud, they can't hear what we
say. I value honesty -- and they might too, but they still won't want to
work with a team who simply stands by their honest estimates. They can
trust their character, but not their competence. Keep in mind too, that
opinion isn't fact, so there is no honesty in estimates except that we are

honestly opening up the floodgates of our internal emotions and
suppositions. I'd expect their response to me doing this would be: "I'm
your customer, not your shrink."

Best,
Bill

William E. Caputo
ThoughtWorks, Inc.
http://www.williamcaputo.com
--------
Never get so caught up in cutting wood that you forget to sharpen your ax.




Yahoo! Groups Links










This email may contain privileged/confidential information. You may not copy or disclose this email to anyone without the written permission of the sender. If you have received this email in error please kindly delete this message and notify the sender. Opinions expressed in this email are those of the sender and not necessarily the opinions of the employer.

This email and any attached files should be scanned to detect viruses. No liability will be accepted by the employer for loss or damage (whether caused by negligence or not) as a result of email transmission.

[William E Caputo]

>Bill:
>> Maybe they apply their own 'Kentucky windage' and 'yesterday's weather'

>> and they intend to use past experience to do so. They have plans to
make

>> too. But are we helping them plan effectively?

>> They can't if we overpromise and underdeliver, because they have open
>> downside risk (i.e. they don't know how much to adjust).

Ben:
>What if they use yesterday's weather to assume that we have overpromised
>and will under deliver by about as much as last time?

I think they probably will -- if trust is high. But then if trust is high,
just about every strategy can work. The tricky part is building trust in
the first place.

Best,
Bill

William E. Caputo
ThoughtWorks, Inc.
http://www.williamcaputo.com
--------
Never get so caught up in cutting wood that you forget to sharpen your ax.

[J. B. Rainsberger]

Ron Jeffries wrote:
> On Tuesday, March 15, 2005, at 3:57:11 PM, J. B. Rainsberger wrote:
>
>
>>As I read all these messages in one session, I formed this impression
>>that many of us are perfectly all right with disbelieving the plan. I
>>think that's quite realistic of us. Still, I wonder how many of our
>>customers think quite so realistically. I have worked with one or two,
>>but not many. In most cases, customers still expect us to deliver what
>>we plan to deliver most of the time.
>
> Many do say that. But what is it in their lives that leads them to
> believe that plans are usually met? I ask this because I believe
> that their experience does not lead them to believe that ... and
> that they express that expectation of perfection to us for another
> reason than that they really expect it.

Sometimes I have to believe something because not believing it is just
too painful to consider. This is true both within and outside the
context of software projects.
--
J. B. (Joe) Rainsberger
Diaspar Software Services
http://www.diasparsoftware.com
Author, JUnit Recipes: Practical Methods for Programmer Testing

[Dale Emery]

Hi Ron,

> But what is it in their lives that leads them to believe that
> plans are usually met? I ask this because I believe that their
> experience does not lead them to believe that ... and that
> they express that expectation of perfection to us for another
> reason than that they really expect it.

I'm convinced that much of the time people simply don't attend to
their disconfirming experience. I'm not sure why that is, but I
think it's common.

Developers often estimate tasks based on a few unwarranted
assumptions: that things will go well, that they won't be
interrupted, and probably some others. For some reason, they
don't consider that everything in their experience screams that
things won't go entirely well, and that they will be interrupted.

Managers often do the same thing when estimating tasks that other
people will do. And if the manager became a manager based on
being a technical wizard, they often introduce another error:
They estimate the task based on how long it would take /them/ to
do it, even if the people who will do the work are less skilled.

I think those errors happen a lot, and account for much of the
unwarranted optimism in estimates.

I think managers sometimes introduce a political game. They have
no hope of hitting the target date, but they don't have the
courage to say that to their bosses. So they do what seems to
them to be the next best thing: spread the blame. The game is
to invite developers to absorb the blame for lateness. Some
developers join the game knowingly. Others get pulled into the
game merely through their optimism.

The manager "wins" by being able to say, "Hey, what could I do?
The developers told me ..." Developers "win" by being able to
continue the game (by being "team players"). And an
unsophisticated customer, who doesn't understand the technical
stuff well enough to make sense of the estimates or the reasons
reasons behind them, is sadly likely to buy that crap.

This political game is, to my way of thinking, embezzlement and
financial fraud. I mean that literally and not metaphorically.

Dale

--
Dale Emery, Consultant
Inspiring Leadership for Software People
Web: http://www.dhemery.com
Weblog: http://www.dhemery.com/cwd

Alliance, n. In international politics, the union of two thieves
who have their hands so deeply inserted in each other's pockets
that they cannot separately plunder a third. --Ambrose Bierce

[Ilja Preuss]

J. B. Rainsberger wrote:

> As I read all these messages in one session, I formed this impression
> that many of us are perfectly all right with disbelieving the plan. I
> think that's quite realistic of us. Still, I wonder how many of our
> customers think quite so realistically. I have worked with one or two,
> but not many. In most cases, customers still expect us to deliver what
> we plan to deliver most of the time.

Isn't that most likely a communication problem? Why, when we plan to deliver
"something around 10, surely 8, perhaps 12 if it goes well" - why does the
customer hear "they promised to deliver 10, and if they deliver only 8 they
failed"?

Curious, Ilja

[Ilja Preuss]

Kent Beck wrote:

> Why not commit to what we can commit to
> and separate that from our wish list. If we are better than
> we actually are, there is nothing to stop us from hitting the wish
> list.

I follow you up to here.

But, you seem to be saying that we shouldn't have the next most valuable
story on the top of our wish list, but something less valuable. That's what
I don't get...

Confused, Ilja

[Ilja Preuss]

I'm currently reading "Agile Development with ICONIX Process", and there is
one interesting technique in the planning chapter:

Plan three kinds of stories for an iteration: those that we are sure we can
do, those that we are likely to do and those that we are unlikely to do, but
will do if time permits (the wish list).

They recommend a 80/20/10 percent distribution, but I think you could even
extrapolate good values from the team's history of velocity.

Could that help improve the relationship to the Customer (if necessary)?

Regards, Ilja

[J. B. Rainsberger]

Ilja Preuss wrote:
> Kent Beck wrote:
>
>
>>Why not commit to what we can commit to
>>and separate that from our wish list. If we are better than
>>we actually are, there is nothing to stop us from hitting the wish
>>list.
>
>
> I follow you up to here.
>
> But, you seem to be saying that we shouldn't have the next most valuable
> story on the top of our wish list, but something less valuable. That's what
> I don't get...

Let me suggest a different dichotomy. Rather than "more valuable" v.
"less valuable", let us discuss "production stories" v. "production
capacity stories".

Some stories are about delivering business value now. Some stories are
about delivering more business value later. The latter stories are
things like practice, play, research.

In every iteration, we should schedule some production stories and some
production capacity stories, recognizing that production levels degrade
over time if we don't pay attention to maintaining production capacity.
--
J. B. (Joe) Rainsberger
Diaspar Software Services
http://www.diasparsoftware.com
Author, JUnit Recipes: Practical Methods for Programmer Testing

[Ron Jeffries]

On Tuesday, March 15, 2005, at 4:00:56 PM, J. B. Rainsberger wrote:

> Let me suggest a different dichotomy. Rather than "more valuable" v.
> "less valuable", let us discuss "production stories" v. "production
> capacity stories".

> Some stories are about delivering business value now. Some stories are
> about delivering more business value later. The latter stories are
> things like practice, play, research.

> In every iteration, we should schedule some production stories and some
> production capacity stories, recognizing that production levels degrade
> over time if we don't pay attention to maintaining production capacity.

That's interesting ... let's run with it a bit.

Ron Jeffries
www.XProgramming.com
Think! -- Aretha Franklin

[Ilja Preuss]

J. B. Rainsberger wrote:

> Let me suggest a different dichotomy. Rather than "more valuable" v.
> "less valuable", let us discuss "production stories" v. "production
> capacity stories".
>
> Some stories are about delivering business value now. Some stories are
> about delivering more business value later. The latter stories are
> things like practice, play, research.
>
> In every iteration, we should schedule some production stories and
> some production capacity stories, recognizing that production levels
> degrade over time if we don't pay attention to maintaining production
> capacity.

I agree that we need to do prodcution capacity tasks. I agree that slack is
a good thing. In fact we just had a team meeting where we decided to more
consciously include slack into our planning.

It's not clear to me, though, that scheduling slack as low priority stories
is a good thing to handle it in most situations, or better than having slack
just being part of Sustainable Pace and Yesterday's Weather. It actually
seems to *play down* the importance of those tasks, compared to just doing
them because they are part of professional behaviour, and measuring how many
"real" stories we actually can do.

We *do* plan to use "slack stories" in the future, but mainly for one
reason: they were violently ignored in the past, so working on the pile of
production capacity tasks (that build up in the years) in an uncontrolled
manner could ruin the company (and once nearly did in the past). For a
starting project, I'd prefer those tasks not to pile up to begin with, and
I'm not convinced that doing them only if there is still time at the end of
an iteration is a good way to do that.

But it's quite possible that I'm misinterpreting and/or overreacting because
of this experience... ;)

Regards, Ilja

[J. B. Rainsberger]

Ilja Preuss wrote:
> J. B. Rainsberger wrote:
>
>
>>Let me suggest a different dichotomy. Rather than "more valuable" v.
>>"less valuable", let us discuss "production stories" v. "production
>>capacity stories".
>>
>>Some stories are about delivering business value now. Some stories are
>>about delivering more business value later. The latter stories are
>>things like practice, play, research.
>>
>>In every iteration, we should schedule some production stories and
>>some production capacity stories, recognizing that production levels
>>degrade over time if we don't pay attention to maintaining production
>>capacity.
>
> I agree that we need to do prodcution capacity tasks. I agree that slack is
> a good thing. In fact we just had a team meeting where we decided to more
> consciously include slack into our planning.
>
> It's not clear to me, though, that scheduling slack as low priority stories
> is a good thing to handle it in most situations, or better than having slack
> just being part of Sustainable Pace and Yesterday's Weather.

This is precisely why I'd like to eliminate "low priority" v. "high
priority" in this discussion. I don't think it's helping us.

> It actually
> seems to *play down* the importance of those tasks, compared to just doing
> them because they are part of professional behaviour, and measuring how many
> "real" stories we actually can do.

It's easy to get wrapped up in production and forget about production
capacity. We're professional, but we're professional /humans/.

> We *do* plan to use "slack stories" in the future, but mainly for one
> reason: they were violently ignored in the past, so working on the pile of
> production capacity tasks (that build up in the years) in an uncontrolled
> manner could ruin the company (and once nearly did in the past). For a
> starting project, I'd prefer those tasks not to pile up to begin with, and
> I'm not convinced that doing them only if there is still time at the end of
> an iteration is a good way to do that.

Exactly. We have seen a few manifestations of this in the literature,
such as Gold Stories (or Gold Coins, or whatever it was called). Kent
mentioned "Geek Week". There are others I'm sure I don't remember.
--
J. B. (Joe) Rainsberger
Diaspar Software Services
http://www.diasparsoftware.com
Author, JUnit Recipes: Practical Methods for Programmer Testing

[William Pietri]

On Wed, 2005-03-16 at 12:07 -0500, J. B. Rainsberger wrote:
> >>Let me suggest a different dichotomy. Rather than "more valuable" v.
> >>"less valuable", let us discuss "production stories" v. "production
> >>capacity stories".
> >
> > I agree that we need to do prodcution capacity tasks. I agree that slack is
> > a good thing. In fact we just had a team meeting where we decided to more
> > consciously include slack into our planning.
> >
> > It's not clear to me, though, that scheduling slack as low priority stories
> > is a good thing to handle it in most situations, or better than having slack
> > just being part of Sustainable Pace and Yesterday's Weather.
>
> This is precisely why I'd like to eliminate "low priority" v. "high
> priority" in this discussion. I don't think it's helping us.

I'd agree with that. Indeed, I avoid scheduling "production capacity
stories" (which I think of as techie tasks) as stories at all, because I
like the main focus to be on the kinds of visible results that the
business cares about.

Act a current client, the right quarter of the whiteboard is a list of
things that the product manager rarely cares about, but that are
important to the developers. It includes refactorings, tools that would
be nice to have, code cleanups, research on external libraries, and
other things that the geeks see as important but are hard to tie to any
particular story card. They aren't scheduled, but are picked up when a
developer has a spare moment.

So if slack is just about making sure there's usually room for those
important-but-not-urgent things, I'm all for it. I'm hoping that the
notion of scheduling silver business instead of gold to provide a buffer
was a misstatement, as that's the part I can't quite swallow.

William

--
William Pietri <william-***@public.gmane.org>

[Dale Emery]

Hi J. B.,

> Let me suggest a different dichotomy. Rather than "more
> valuable" v. "less valuable", let us discuss "production
> stories" v. "production capacity stories".

I had the same thought.

The distinction is already built into XP at the smallest scale:
The red/green/refactor cycle of TDD. The "green" step creates
product. The "refactor" step creates production capacity (in
particular, maintainability and enhanceability).

It's also built into the rules of simplicity: The "passes all
the tests" criterion is a test of product. The other criteria
are tests of production capacity.

What if, by the principle of self similarity, we made production
capacity explicit in the larger scale cycles?

Dale

--
Dale Emery, Consultant
Inspiring Leadership for Software People
Web: http://www.dhemery.com
Weblog: http://www.dhemery.com/cwd

I was so surprised at being born that I didn't speak for a year
and a half. --Gracie Allen

[Tim King]

Kent Beck wrote:
> What will you do if you can't force the customer to understand? How about
> having a list of commitments and a wish list you could chose from if you are
> quicker and cleverer than you think you are? Could your customers understand
> that?

Yes, I think so. That's close to what I'm doing now. This means I
schedule conservatively, so that I can make my estimate. The problem
with scheduling conservatively is Parkinson's Law. Yes, I know,
Parkinson's Law isn't a real law; it's just a humorous aside. But I have
noticed at least my own velocity and energy decreasing when I pad my
estimates in this way.

Of course, the real issue is trust. How strong or fragile is the
customer's trust? Right now, I have a customer who brings up issues as
though they were someone's fault and seems to be afraid I'm going to
turn around and blame him, though I never do. The trust in the
relationship is especially fragile. I think that strikes to the heart.
You need trust in order for real teamwork to happen.

So maybe we should consider tweaking the schedule as a stop-gap measure
to establish a relationship, _if_ it works to establish the
relationship, but always strive to schedule the highest-priority stories
we can.

-TimK
--
J. Timothy King ..team-oriented..object-oriented..Agile..
www.jtse.com ..C++..Perl..Java..assembly..embedded.systems..

[Dave Rooney]

> -----Original Message-----
> From: Ilja Preuss [mailto:preuss-XAcXpg+***@public.gmane.org]
> Sent: Friday, March 04, 2005 10:29 AM
> To: xpbookdiscussiongroup-***@public.gmane.org
> Subject: RE: [xpe2e] Planning game confusion
>
>
>
> I'm currently reading "Agile Development with ICONIX
> Process", and there is one interesting technique in the
> planning chapter:
>
> Plan three kinds of stories for an iteration: those that we
> are sure we can do, those that we are likely to do and those
> that we are unlikely to do, but will do if time permits (the
> wish list).
>
> They recommend a 80/20/10 percent distribution, but I think
> you could even extrapolate good values from the team's
> history of velocity.
>
> Could that help improve the relationship to the Customer (if
> necessary)?

Isn't Doug Rosenberg (of XP: Refactored fame) behind INCONIX?

I guess while bashing XP he actually found some good ideas.

Dave Rooney
Mayford Technologies
http://www.mayford.ca

[Ilja Preuss]

Dave Rooney wrote:

> Isn't Doug Rosenberg (of XP: Refactored fame) behind INCONIX?

Yes. Matt also coauthored the ICONIX book, together with a third author
(currently don't remember the name).

> I guess while bashing XP he actually found some good ideas.

The ICONIX book isn't as bad as the XPR one, though also not as good and
informative as I hoped - it contains a lot of solid advice (especially the
planning part), a slightly annyoing amount of circumstantial chattiness, the
expected amount of "constant refactoring after programming paranoia", and a
handfull of gross misconceptions about other Agile methods, especially XP.

Cheers, Ilja

[Luiz Esmiralha]

Hi Dave,

I fail to see anything new in ICONIX approach. Categorizing stories by
their business value (must do, should do, nice to do, etc.) and
selecting a mix of stories that contemplates every category for every
iteration is a common practice. Also XPE2E describes the practice of
introducing Slack (stories of low business value that can be dropped
without much trouble) on every iteration to give some flexibility.

What I read about ICONIX (not much I must say) is that it preaches
full traceability between code constructs and UML artifacts and a
somewhat rigid division of labor between coders and software designers
that I find unhealthy in the long run.

Best regards,
Luiz

On Fri, 4 Mar 2005 11:15:19 -0500, Dave Rooney <dave.rooney-JZ+f107kGBmw5LPnMra/***@public.gmane.org> wrote:
> > -----Original Message-----
> > From: Ilja Preuss [mailto:preuss-XAcXpg+***@public.gmane.org]
> > Sent: Friday, March 04, 2005 10:29 AM
> > To: xpbookdiscussiongroup-***@public.gmane.org
> > Subject: RE: [xpe2e] Planning game confusion
> >
> >
> >
> > I'm currently reading "Agile Development with ICONIX
> > Process", and there is one interesting technique in the
> > planning chapter:
> >
> > Plan three kinds of stories for an iteration: those that we
> > are sure we can do, those that we are likely to do and those
> > that we are unlikely to do, but will do if time permits (the
> > wish list).
> >
> > They recommend a 80/20/10 percent distribution, but I think
> > you could even extrapolate good values from the team's
> > history of velocity.
> >
> > Could that help improve the relationship to the Customer (if
> > necessary)?
>
> Isn't Doug Rosenberg (of XP: Refactored fame) behind INCONIX?
>
> I guess while bashing XP he actually found some good ideas.
>

[Ilja Preuss]

Luiz Esmiralha wrote:
> Hi Dave,
>
> I fail to see anything new in ICONIX approach. Categorizing
> stories by their business value (must do, should do, nice to
> do, etc.) and selecting a mix of stories that contemplates
> every category for every iteration is a common practice.

I didn't know that it is a common practice for "XP teams". Is it? Is it for
"SCRUMM teams" etc.?

Also, I don't think that categorizing stories by business value and
categorizing them by probability of completion in an iteration is exactly
the same thing.

> Also
> XPE2E describes the practice of introducing Slack (stories of
> low business value that can be dropped without much trouble)
> on every iteration to give some flexibility.

Yes, I understand that. As I said above, I don't think that "will do if time
permits" has to be even nearly the same as "has low business value".

> What I read about ICONIX (not much I must say) is that it
> preaches full traceability between code constructs and UML
> artifacts and a somewhat rigid division of labor between
> coders and software designers that I find unhealthy in the long run.

The former is somewhat hard to tell from the book (that's one of my main
problems with it), but the latter definitely isn't true for "agile ICONIX".

Cheers, Ilja

[Luiz Esmiralha]

On Mon, 7 Mar 2005 15:53:17 +0100, Ilja Preuss <preuss-XAcXpg+***@public.gmane.org> wrote:
> Luiz Esmiralha wrote:
> > Hi Dave,
> >
> > I fail to see anything new in ICONIX approach. Categorizing
> > stories by their business value (must do, should do, nice to
> > do, etc.) and selecting a mix of stories that contemplates
> > every category for every iteration is a common practice.
>
> I didn't know that it is a common practice for "XP teams". Is it? Is it for
> "SCRUMM teams" etc.?
>

Hmm, actually I can't say it's a common practice among the community.
I usually categorize stories by business value in my daily practice.

> Also, I don't think that categorizing stories by business value and
> categorizing them by probability of completion in an iteration is exactly
> the same thing.
>

You are right. These are different things. Probability of completion
would be the same as accuracy of estimate as described in XPE1E (can
estimate with a lot of confidence, can estimate with a little
confidence, can't estimate at all)?

> > Also
> > XPE2E describes the practice of introducing Slack (stories of
> > low business value that can be dropped without much trouble)
> > on every iteration to give some flexibility.
>
> Yes, I understand that. As I said above, I don't think that "will do if
> time
> permits" has to be even nearly the same as "has low business value".
>

Yes, I agree you could schedule a high value story as "optional". On
the other hand, a high value story potentially creates a lot of
expectative on the part of the Customer and dropping it may create
some unnecessary disappointment. It depends on the relationship you
have with the Customer.

> > What I read about ICONIX (not much I must say) is that it
> > preaches full traceability between code constructs and UML
> > artifacts and a somewhat rigid division of labor between
> > coders and software designers that I find unhealthy in the long run.
>
> The former is somewhat hard to tell from the book (that's one of my main
> problems with it), but the latter definitely isn't true for "agile ICONIX".
>

Well, I actually read a little about ICONIX and watched a presentation
that may have left me with a wrong impression. I will definitely try
to read the official book to get a clearer view of the process.

Thanks a lot,
Luiz

[Ilja Preuss]

Luiz Esmiralha wrote:

>> Also, I don't think that categorizing stories by business value and
>> categorizing them by probability of completion in an iteration is
>> exactly the same thing.
>>
>
> You are right. These are different things. Probability of
> completion would be the same as accuracy of estimate as
> described in XPE1E (can estimate with a lot of confidence,
> can estimate with a little confidence, can't estimate at all)?

I don't think so. For example, we could have low confidence in the estimate
of the first (most important) story, but still be confident that we can
finish it in the current iteration. We then just wouldn't be as sure how
many of the others stories we'd finish additionally.

> Yes, I agree you could schedule a high value story as
> "optional". On the other hand, a high value story potentially
> creates a lot of expectative on the part of the Customer and
> dropping it may create some unnecessary disappointment. It
> depends on the relationship you have with the Customer.

Agreed. I'd probably think of the desire to schedule a less valuable story
as a "relationship smell", though. That's not to say that I wouldn't do it -
I'd just at the same time try to find ways to improve the relationship to
remove that desire.

> Well, I actually read a little about ICONIX and watched a
> presentation that may have left me with a wrong impression. I
> will definitely try to read the official book to get a clearer view
> of the process.

Actually after reading (only) the "Agile ICONIX" book, my view of the
process is still quite nebulous, so I don't think I can really recommend it.

Cheers, Ilja

[Jeff Nielsen]

From: "Ilja Preuss" <preuss-XAcXpg+***@public.gmane.org>
> I'm currently reading "Agile Development with ICONIX Process", and there
> is
> one interesting technique in the planning chapter:
>
> Plan three kinds of stories for an iteration: those that we are sure we
> can
> do, those that we are likely to do and those that we are unlikely to do,
> but
> will do if time permits (the wish list).
>
> They recommend a 80/20/10 percent distribution, but I think you could even
> extrapolate good values from the team's history of velocity.
>

This is like the MoSCoW rules from DSDM (see
http://na.dsdm.org/en/about/moscow.asp), which we have adapted successfully
for iteration planning. We commit to a set of "Must Have" stories, which we
will deliver no matter what. We also talk with the customer about "Should
Have" stories, of which some will probably make it in to the iteration. The
"Could Have" stories are stretch goals, to be completed if the stars align
properly.

We use a combination of past velocity and the project's buffer to know where
to draw the lines. Here's a simple example:

Must Haves: Story A (2 pts), Story G (2 pts), Story Z (1 pt), Story R (4
pts), Story Q (1 pt)
Should Haves: Story B (1 pt), Story M (3 pts)
Could Haves: Story L (2 pts)

Jeff Nielsen
Digital Focus
www.digitalfocus.com

[Ilja Preuss]

Jeff Nielsen wrote:
> From: "Ilja Preuss" <preuss-XAcXpg+***@public.gmane.org>
>> I'm currently reading "Agile Development with ICONIX Process", and
>> there is
>> one interesting technique in the planning chapter:
>>
>> Plan three kinds of stories for an iteration: those that we are sure
>> we can
>> do, those that we are likely to do and those that we are unlikely to
>> do, but will do if time permits (the wish list).
>>
>> They recommend a 80/20/10 percent distribution, but I think you could
>> even extrapolate good values from the team's history of velocity.
>>
>
> This is like the MoSCoW rules from DSDM (see
> http://na.dsdm.org/en/about/moscow.asp), which we have adapted
> successfully for iteration planning. We commit to a set of "Must
> Have" stories, which we will deliver no matter what. We also talk
> with the customer about "Should Have" stories, of which some will
> probably make it in to the iteration. The "Could Have" stories are
> stretch goals, to be completed if the stars align properly.

It seems to me that we could have stories planned for the end of an
iteration that are fundamental for the projects success, but might only be
done *in this iteration* if time permits. I think that would be better than
scheduling "nice to have features", in many cases.

Cheers, Ilja

[Jeff Nielsen]

From: "Ilja Preuss" <preuss-XAcXpg+***@public.gmane.org>

> Jeff Nielsen wrote:
>> This is like the MoSCoW rules from DSDM (see
>> http://na.dsdm.org/en/about/moscow.asp), which we have adapted
>> successfully for iteration planning. We commit to a set of "Must
>> Have" stories, which we will deliver no matter what. We also talk
>> with the customer about "Should Have" stories, of which some will
>> probably make it in to the iteration. The "Could Have" stories are
>> stretch goals, to be completed if the stars align properly.
>
> It seems to me that we could have stories planned for the end of an
> iteration that are fundamental for the projects success, but might only be
> done *in this iteration* if time permits. I think that would be better
> than
> scheduling "nice to have features", in many cases.
>

You're right, it's not a good mapping between the way DSDM uses the MoSCoW
rules--for scoping an entire release. I didn't mean to imply that we
schedule stories for an iteration that are only "nice to have" for the
project. We use it more in the way you suggest--this iteration's "Could
Have" stories often become next iteration's "Must Haves" if they don't get
completed, because we ware working in terms of highest value for the
project.

I mostly like the idea of making the uncertainty about what will get done
*in a single iteration* explicit through a catchy labeling convention.

Jeff

[Brad Appleton]

Ilja Preuss wrote:
> Jeff Nielsen wrote:
> > This is like the MoSCoW rules from DSDM (see
> > http://na.dsdm.org/en/about/moscow.asp), which we have adapted
> > successfully for iteration planning. We commit to a set of "Must
> > Have" stories, which we will deliver no matter what. We also talk
> > with the customer about "Should Have" stories, of which some will
> > probably make it in to the iteration. The "Could Have" stories are
> > stretch goals, to be completed if the stars align properly.
>
> It seems to me that we could have stories planned for the end of an
> iteration that are fundamental for the projects success, but might only be
> done *in this iteration* if time permits. I think that would be better than
> scheduling "nice to have features", in many cases.

What Ive done several times in the past that has worked successfully for
my teams is that we used something we called an "Uncommitted"
list/backlog. Im not particularly fond of the name, but the basic gist
of it was that it contained those "stories" not currently committed to
the current iteration but which have
* the highest priority of all the stories not in this iteration
* a plausible chance of being able to accommodate in the current iteration

This was our way of managing expectations with our customer by
explicitly acknowledging that there was stuff they wanted that didnt
make the current iteration that was still pretty darn important, and
that we would make a deliberate effort to see if/when the "next highest"
priority stories had a chance of making it in this iteration.

This helped us in two ways:
* the overall story backlog (what SCRUM would call the "Product"
backlog, as opposed to the current Sprint (iteration) backlog) was kind
of large and sometimes unwieldy
* when customers evaluated an executable result in the middle or end of
an iteration, it was easy for them to look at the handful of requests on
the "Uncommitted" list and quicly decide the the enhancement they just
thought of should be done in the current/subsequent iteration of if
something on the uncommitted list was more valuable to them. This helped
reduce "gold-plating"



--
Brad Appleton <brad-***@public.gmane.org> www.bradapp.net
Software CM Patterns (www.scmpatterns.com)
Effective Teamwork, Practical Integration
"And miles to go before I sleep" --Robert Frost

[BenAveling]

Kent Beck wrote:

>Something that bothers me about this whole discussion is people's apparent
>need to wring every last iota of value out of development.
>

Hi Kent,

I acknowledge that maximizing output had trade offs, sometimes
inappropriate ones. Consider this an exercise in understanding the
trade offs.

As I understand the thread, the key question is, given that there is
always some variation in velocity, how to manage the reaction to those
iterations where productivity is at the low end of the scale?

Should we try to manage expectations by including in each iteration some
features that aren't quite as valuable (silver coins, if you like), on
the grounds that a short-fall might then be less painful?

Or should we always focus on the highest value features (the gold coins)
on the grounds that this gives the highest return on average, at the
cost of sometimes falling short of expectations?

Or is this a false dichotomy?

>If the company
>really is going to fold if you get widget X done on Tuesday instead of
>Monday, you already have bigger problems than can be solved by programming.
>
>

Agreed, so long as you're not writing software for the Olympic games
opening ceremony or such like.

To revisit the metaphor, suppose we were choosing between :
a) 12 gold coins this week followed by 12 silver coins next week
or
b) 8 gold coins plus 4 silver coins this week followed by 4 gold
coins and 8 silver coins next week.

Sometimes, there isn't much to choose between these two options. In each
case, you have 12 gold and 12 silver coins.

But more often, it isn't just a case of swapping things by one week.

Sometimes, the choice is:
c) 12 gold coins this week and 12 gold coins next week and 12 gold
coins the next and so on.
or
d) 8 gold coins plus 4 silver coins this week and 8 gold coins and 4
silver coins next week and so on.

Creating gold instead of silver this week doesn't always mean that we
can't create gold next week as well. Often, it just means that at the
end of the year we have more gold and less silver.

Of course, software development isn't ever that predictable. Some weeks
we will produce 12, some weeks we won't. Early on, we have very little
idea how many coins we should expect.

In exchange for having more gold at the end, we'll certainly have
disappointed the customer more than a few times between now and then.

>Most of the time while what we're doing is valuable, it just isn't that
>important. That's not an excuse not to do our best, but packing schedules so
>they look more impressive and risking a weekly disintegration of our
>relationship to our customers doesn't make sense.
>

I'm not necessarily arguing for packing more into the schedule. The
question is more do we front load the most valuable features?

>Why not commit to what we
>can commit to and separate that from our wish list?
>

Because human nature is not to deliver on the wish list, and every
manager knows it.

A common expectation is that employees sometimes underdeliver but never
overdeliver. Given that assumption, logic says that goals always should
set as high as possible, or higher, and that aiming low
(under-promising) is a larger sin than under-delivering slightly, which
just shows you set the right target.

There is another school of thought that says that an unexpected loss of
a given size cause more pain than an unexpected gain of the same size.
Given that assumption, logic says goals should be set at whatever level
we are sure of delivering, or slightly lower.

Then there are people who value certainty above all else, they like to
plan ahead and they dislike replanning. Either aiming low or high would
cause pain.

And then there are risk tolerant people who don't mind plans changing
regularly and who will cope with the occasional bad outcome in exchange
for a higher average return. They prefer maximizing the return each and
every week, even at the cost of long term certainty.


>If we are better than we
>actually are, there is nothing to stop us from hitting the wish list.
>
>

Well put. Of course we aren't better than we actually are, although
many people schedule that way: take the best possible case, call it your
expectation, then commit to it. The only way to succeed doing that is
to make a mistake and somehow underestimate velocity.

Another common mistake is to take the average and commit to that. The
average is a reasonable expectation but it's not a reasonable thing to
commit to because about half the time you fall short. On the other
hand, at most companies in this industry, falling short only half of the
time would be a good outcome .

This leads to another problem: finishing early can get you punished.
Call me cynical, but many managers have the mind-set that if you
finished early, you must have lied on your estimates, or at best, made
some big mistakes. No one wants you to be very late, but less than
'fashionably late' can also be unwelcome.

So the easy answer is that there is no easy answer. There is no
strategy that is always best . Which is best in a given situation
depends on the situation, and your temperament and on that of your customer.

Personally, I like to aim high, but I realize that doesn't suit
everybody. Such is life.

Regards, Ben

[Ron Jeffries]

Hi Ben,

I like the thinking you offer in your post, a bit of which is
included below. (I like the whole thing but wanted to save some
bits, so I just included enough to entice people to read your note
again.)

It's natural to be afraid of displeasing the customer, and natural
to want to minimize any disappointments. You mention some of the
alternative approaches including:

Reduce expectations by promising less than we can do, then
over-delivering;

Reduce disappointment by promising less valuable things than we
might do, reducing the sense of loss if we fall short.

Maximize return by attempting the most valuable things we might
do.

Perhaps you have most closely touched the real issue when you talk
about the various forms of human response: management expectations
of under- but not over-delivery; disproportionate feelings of loss
compared to gains; need for certainty; risk tolerance.

We have started looking at the idea of picking silver stories
instead of gold, I guess to reduce the pain of loss. I've
facetiously suggested carrying this to the extreme of scheduling a
customer root canal as the last story in each iteration so that
she'll be delighted that we have fallen short yet again. Yet there's
a real idea behind that absurdity: perhaps we shouldn't ever try to
accomplish things we don't really want; we should try to accomplish
things that we do want.

With this in mind, I'd like to return to some basics.

The customer decides what the team will work on. The [programmer]
team decides how much work they can do. With this basic in place,
the customer can choose the root canal to decrease her sense of
loss on a missed story, or choose the next most valuable story if
she's feeling optimistic.

Now I would not advise choosing less valuable stories as a matter
of course: It seems to me to be a discernibly inferior strategy.
But I'm comfortable mentioning it as a possibility for a company,
team, or customer, in whom fear of loss is high.

Therefore, we are opening the door to choosing stories differently
based on their probability of completion. OK, I think that's odd,
but I'm frequently wrong.

Suppose, then, that we want to choose stories differently based on
the chance of completion. What are some good ways to estimate,
communicate, and track that chance?

Ron Jeffries
www.XProgramming.com
A lot of preconceptions can be dismissed when you actually
try something out. -- Bruce Eckel

On Sunday, March 6, 2005, at 7:22:41 AM, BenAveling wrote:

> I acknowledge that maximizing output had trade offs, sometimes
> inappropriate ones. Consider this an exercise in understanding the
> trade offs.

> As I understand the thread, the key question is, given that there is
> always some variation in velocity, how to manage the reaction to those
> iterations where productivity is at the low end of the scale?

> Should we try to manage expectations by including in each iteration some
> features that aren't quite as valuable (silver coins, if you like), on
> the grounds that a short-fall might then be less painful?

> Or should we always focus on the highest value features (the gold coins)
> on the grounds that this gives the highest return on average, at the
> cost of sometimes falling short of expectations?

> Or is this a false dichotomy?

[Doug Swartz]

Sunday, March 06, 2005, 7:04:40 AM, Ron Jeffries wrote:

> Perhaps you have most closely touched the real issue when you talk
> about the various forms of human response: management expectations
> of under- but not over-delivery; disproportionate feelings of loss
> compared to gains; need for certainty; risk tolerance.

I think you're right that the human response to scheduling and
the outcomes of our efforts are what matter the most.
Unfortunately, not only our velocity, but the human response
to variations in our velocity, are often very difficult to
predict. Here's a little story:

We had a customer we started to work with almost a year ago.
She wasn't particularly sold on our development approach. She
couldn't really see how we could deliver for her without lots
of up-front planning, and she wanted to know for sure what she
was getting when, and how much it would cost her. But she
bought in enough to work with us to create a release plan for
the first 4 months of work.

As it turns out, the team was somewhat more optimistic about
which features we could deliver in how much time. There are
various reasons for the variance from original plans:
An unplanned for trip home to India for a couple of team
members, poor estimates on more than a few cards, not enough
discussion between developers and customers, scope creep at
the card level, all the normal stuff. Suffice to say, the
first release, and both subsequent releases since, have
included significant feature negotiation and adjustment.

And yet... Here we are, working on the third release.
Last Friday, I heard the customer who had been skeptical,
talking about one of the other development groups in the
company. This development group uses a classic waterfall
approach, with much up-front planning, and 4 to 6 weeks of
"QA" at the end. Her comment: "Last week the project was
green, but this week, they're reporting that they're 4 weeks
behind! At least with you guys, I always know where I am!"
Now, I don't think she's quite ready to go on the road to
proselytize for XP. But I believe she's certainly come to see
the value of transparency and, possibly, the value of
iterations which allow adjustment of priorities throughout the
development process.

What's key? Building the relationship through honesty
and communication are key. Whether we schedule 8 gold cards
and 4 silver cards, or 12 gold cards, into an iteration is
much less important than building the community who can play
the cooperative game of building solutions to business
problems. Part of the communication is helping our customers
understand that estimates are not perfect, and slack of some
sort is a wise business decision.



--

Doug Swartz
daswartz-***@public.gmane.org

[Anthony Williams]

Doug Swartz <daswartz-***@public.gmane.org> writes:

> What's key? Building the relationship through honesty
> and communication are key. Whether we schedule 8 gold cards
> and 4 silver cards, or 12 gold cards, into an iteration is
> much less important than building the community who can play
> the cooperative game of building solutions to business
> problems.

Yes. It is more important that the customer knows what the options are, and
which one has been chosen, than which option actually gets chosen.

Anthony
--
Anthony Williams
Software Developer

[Marko van der Puil]

It seems to me Doug is the only one getting the idea:

1) We estimate and schedule with our consience, realistic, as we best
know now and understand.
2) We talk to the customer.

Not "If" but "When" something blows, we tell out customer about it,
immediately. This is important information for the customer, we cannot
afford to wait untill the next Planning Game for that. I wonder; were
did the "no talking to the customer during the iteration" rule come
from? Planning is a continues activity and only valuable as such. A
plan is a deliverable from this activity and has little or no lasting
value.

"We have found an error in our original estimation of your most
valuable story we planned for this release, can we sit down and
discuss our options?"

The plan changes mid-iteration -> Embrace Change

- Honesty builds thrust just as much as delivering on your promises.
- It's not the end of the world if something happens so that you can't
deliver as promised, it's how you react to it that counts.

Communication!
Feedback!
Courage!

Cheers, Marko

> I think you're right that the human response to scheduling and
> the outcomes of our efforts are what matter the most.
> Unfortunately, not only our velocity, but the human response
> to variations in our velocity, are often very difficult to
> predict.

> What's key? Building the relationship through honesty
> and communication are key. Whether we schedule 8 gold cards
> and 4 silver cards, or 12 gold cards, into an iteration is
> much less important than building the community who can play
> the cooperative game of building solutions to business
> problems. Part of the communication is helping our customers
> understand that estimates are not perfect, and slack of some
> sort is a wise business decision.
>
> --
>
> Doug Swartz
> daswartz-***@public.gmane.org

--
Met vriendelijke groet,

Marko van der Puil - marko-***@public.gmane.org - http://www.brains4all.com
Brains4All B.V. - Smart Internet Solutions - Postbus 14 - 4493 ZG - Kamperland

[Ilja Preuss]

Marko van der Puil wrote:
> It seems to me Doug is the only one getting the idea:
>
> 1) We estimate and schedule with our consience, realistic, as
> we best know now and understand.
> 2) We talk to the customer.
>
> Not "If" but "When" something blows, we tell out customer
> about it, immediately. This is important information for the
> customer, we cannot afford to wait untill the next Planning
> Game for that. I wonder; were did the "no talking to the
> customer during the iteration" rule come from? Planning is a
> continues activity and only valuable as such. A plan is a
> deliverable from this activity and has little or no lasting value.

Who said you should not talk to your customer during the iteration?
:confused:

> "We have found an error in our original estimation of your
> most valuable story we planned for this release, can we sit
> down and discuss our options?"
>
> The plan changes mid-iteration -> Embrace Change
>
> - Honesty builds thrust just as much as delivering on your promises.
> - It's not the end of the world if something happens so that
> you can't deliver as promised, it's how you react to it that counts.

As far as I understood Kent, his argument is that what also counts is how
the customer reacts. If he reacts negatively to the fact that we didn't
manage to implement the last important story of an iteration, that might
drive us to commit to less important stories at the end of an iteration
(assuming that the customer might react less negatively).

> Communication!
> Feedback!
> Courage!

True.

Using slack for the above reasons doesn't look the most courageously to me.
It feels more like giving in to our fears instead of working on removing the
cause.

I might be totally wrong, though.

Cheers, Ilja

[Marko van der Puil]

> > It seems to me Doug is the only one getting the idea:

I didn't realise this was a flame indicator, my apologies to the list,
no harm intended. You are all very intelligent and communicative
people and I respect and cherish you for that. My apologies.

> Who said you should not talk to your customer during the iteration?

No one actually said it, but that was the feeling I was getting while
reading this thread.

> As far as I understood Kent, his argument is that what also counts is how
> the customer reacts. If he reacts negatively to the fact that we didn't
> manage to implement the last important story of an iteration, that might
> drive us to commit to less important stories at the end of an iteration
> (assuming that the customer might react less negatively).

Well, I'm having trouble with that kind of commitment. Let me rephrase
it as I understand it:

Sometimes we (XP developers) overcommit ourselves, or something else
bad happens. Therefore sometimes may not be able to finish all of the
valuable work we've planned together with the customer. To solve this
we are now ALWAYS going to plan to deliver LESS VALUE than we actually
know we can. So that when this "sometime" happens, the customer won't
be that dissapointed, because he will lose a story of lesser value,
instead of a high value one.

I can see what might lead to this idea, however I think there are
others ways to address this problem.

> Using slack for the above reasons doesn't look the most courageously to me.
> It feels more like giving in to our fears instead of working on removing the
> cause.
>
> I might be totally wrong, though.

I don't think you are. I was wondering how this apparently fear
motivated practise got into XP.

I've re-read some piece of the XPec2e book today including the bit about Slack.
That bit had me worried.
Slack is good, fear is not.

I also re-read some other bits about the 5 why's, and about planning.
Those bits had me feeling good, and left me puzzled.

The piece about Slack seems to counterintuative to the other pieces
about planning.
Still, slack is a planning tool.
Slack however seems hard to define.
I like the Critical-chain Buffer concept better.
A buffer is there to act like a shock absober. When you hit a bump in
the road, your car still jumps, and your ride might get a little bit
bumpy, but you will not crash from a dump in the road. When there are
no bumps in the road, shock-absorbers get you to your destination
smoothly and safely.

But back to the argument;

This low value story slack is not about structural under-estimation.
We have velocity to calibrate estimates to reality.

It shouldn't be about structural overcommitment, because I think an XP
team can self-reflect sufficiently to be able to signal and abandon
structural overcommitment.

Stories are prioritised according to value. Highest value first. So
you always get the highest value story, right?

So the stories being dropped are always, by definition, lower in value
to the ones realised, right?

XP for me is about exellence, about striving and performing at or
above the levels you have thought yourself capable of. In my opinion,
that includes having the courage and respect to face the customer
incidentally and say; I've been bad, I've made a boo-boo. Because of
that, you will not get all the value we promised. Now can we sit
together and see what we can do about.

It's about risk.

In the example we've been discussing, it is not clear why the incident
has occured that forced us to deliver less value than we promised. I
agree with Ilja, that the root-cause of the problem must be adressed.

Now, we've determined that this sort of slack is used only to cover
incidents, not structural problems. You know you've got a problem
when you haven't been able to deliver upon your promises more than 2
times in a row. That is a sure trust killer, that is.

The problem I'm having with this kind of low-story-slack is that it is
introducing a structual inhibitor for delivering the most value
possible while trying to adress an issue that is by definition
incidental of nature.

Why not be completly open and honest:

"We can commit to this, because this is the least amount of stories
our team has been able to implement in one iteration. There is a
remote change that something bas might happen and that we are forced
to deliver even less. Still, we commit to this amount of work. It is
however far more likely that we will deliver more, since our average
amount of stories delivered in an iteration was that. We have never
delivered more that this other amount of stories in an iteration, so
it is unlikely that we will exceed that. Can you, as our valued
customer, lay all these stories in descending order of value, for you
as you now see it, so we can all know which next story to take should
the likelyhood appear that we finish early?"

You can substitue the least amount of stories ever for any number you
find resonable or fair.

This is how we've been doing it up till now;

We'd like to take our average storypoint delivered minus 2 standard
deviations. In a classic bell-curve, that covers over 95% of the
cases.

We make a release plan that commits to only that amount of
storypoints, and update the plan during the planning game to reflect
reality more and more.

Once every 20 or so iterations something goes wrong. We've build up
enough trust-credit with the customer in the past 19 iterations that I
believe he'll be adamant when we say: "Listen, something went wrong.
Will you work with us because we really want to get back on track as
fast as possible?" If he's not adamant, we could take out the original
release plan and say: "Look, this is how far ahead we are on the
original scedule, cut us some slack..."

Why not solve structural problems structural, and incidental problems
incidental?

Why not face the customer with respect and courage?

I do love the respect value, glad it made it in there.

Cheers, Marko

--
Met vriendelijke groet,

Marko van der Puil - marko-***@public.gmane.org - http://www.brains4all.com
Brains4All B.V. - Smart Internet Solutions - Postbus 14 - 4493 ZG - Kamperland

[Kent Beck]

Marko,

It seems to me that this whole thread has gone off the rails. I'll try to
recap what I think everyone agrees on and then perhaps we can continue from
there. Everyone agrees that we should create as much value as possible.
Arguments of the form, "...but if you could do something more valuable, why
wouldn't you do that?" are not likely to be fair readings of someone else's
ideas.

Slack is not motivated by fear, not for me, unless it is the fear that I
will once again fall into the trap of thinking that if I don't commit beyond
my abilities I will be fired. I am not the only programmer with this
problem. My practice of slack is primarily motivated by my desire to be a
trustworthy partner in a business relationship and only commit to what I can
truly deliver.

Part of the value of slack is the "shock absorber" you mention below. Part
of it is stress relief--it's not good for anyone to go on over-drive all day
every day. Part of it is acknowledging that we don't always know what will
have the most/least value or take the most/least effort. Sometimes something
that seemed like a minor enhancement, ends up being the most compelling
piece of the project. Part of it is acknowledging that we as programmers
have programmer tasks to complete during a development cycle. A good example
of a slack story is tool-smithing, automating some aspect of development.
These are worth doing, but not at the risk of not delivering business
functionality. If you are not overcommitted,you will likely have some free
time here and there. A stack of slack stories are what you reach for at one
of those times.

Kent Beck
Three Rivers Institute

> -----Original Message-----
> From: Marko van der Puil [mailto:marko-***@public.gmane.org]
> Sent: Thursday, March 10, 2005 3:35 PM
> To: xpbookdiscussiongroup-***@public.gmane.org
> Subject: Re: Re[2]: [xpe2e] Planning game confusion
>
>
> > > It seems to me Doug is the only one getting the idea:
>
> I didn't realise this was a flame indicator, my apologies to the list,
> no harm intended. You are all very intelligent and communicative
> people and I respect and cherish you for that. My apologies.
>
> > Who said you should not talk to your customer during the iteration?
>
> No one actually said it, but that was the feeling I was getting while
> reading this thread.
>
> > As far as I understood Kent, his argument is that what also
> counts is how
> > the customer reacts. If he reacts negatively to the fact
> that we didn't
> > manage to implement the last important story of an
> iteration, that might
> > drive us to commit to less important stories at the end of
> an iteration
> > (assuming that the customer might react less negatively).
>
> Well, I'm having trouble with that kind of commitment. Let me rephrase
> it as I understand it:
>
> Sometimes we (XP developers) overcommit ourselves, or something else
> bad happens. Therefore sometimes may not be able to finish all of the
> valuable work we've planned together with the customer. To solve this
> we are now ALWAYS going to plan to deliver LESS VALUE than we actually
> know we can. So that when this "sometime" happens, the customer won't
> be that dissapointed, because he will lose a story of lesser value,
> instead of a high value one.
>
> I can see what might lead to this idea, however I think there are
> others ways to address this problem.
>
> > Using slack for the above reasons doesn't look the most
> courageously to me.
> > It feels more like giving in to our fears instead of
> working on removing the
> > cause.
> >
> > I might be totally wrong, though.
>
> I don't think you are. I was wondering how this apparently fear
> motivated practise got into XP.
>
> I've re-read some piece of the XPec2e book today including
> the bit about Slack.
> That bit had me worried.
> Slack is good, fear is not.
>
> I also re-read some other bits about the 5 why's, and about planning.
> Those bits had me feeling good, and left me puzzled.
>
> The piece about Slack seems to counterintuative to the other pieces
> about planning.
> Still, slack is a planning tool.
> Slack however seems hard to define.
> I like the Critical-chain Buffer concept better.
> A buffer is there to act like a shock absober. When you hit a bump in
> the road, your car still jumps, and your ride might get a little bit
> bumpy, but you will not crash from a dump in the road. When there are
> no bumps in the road, shock-absorbers get you to your destination
> smoothly and safely.
>
> But back to the argument;
>
> This low value story slack is not about structural under-estimation.
> We have velocity to calibrate estimates to reality.
>
> It shouldn't be about structural overcommitment, because I think an XP
> team can self-reflect sufficiently to be able to signal and abandon
> structural overcommitment.
>
> Stories are prioritised according to value. Highest value first. So
> you always get the highest value story, right?
>
> So the stories being dropped are always, by definition, lower in value
> to the ones realised, right?
>
> XP for me is about exellence, about striving and performing at or
> above the levels you have thought yourself capable of. In my opinion,
> that includes having the courage and respect to face the customer
> incidentally and say; I've been bad, I've made a boo-boo. Because of
> that, you will not get all the value we promised. Now can we sit
> together and see what we can do about.
>
> It's about risk.
>
> In the example we've been discussing, it is not clear why the incident
> has occured that forced us to deliver less value than we promised. I
> agree with Ilja, that the root-cause of the problem must be adressed.
>
> Now, we've determined that this sort of slack is used only to cover
> incidents, not structural problems. You know you've got a problem
> when you haven't been able to deliver upon your promises more than 2
> times in a row. That is a sure trust killer, that is.
>
> The problem I'm having with this kind of low-story-slack is that it is
> introducing a structual inhibitor for delivering the most value
> possible while trying to adress an issue that is by definition
> incidental of nature.
>
> Why not be completly open and honest:
>
> "We can commit to this, because this is the least amount of stories
> our team has been able to implement in one iteration. There is a
> remote change that something bas might happen and that we are forced
> to deliver even less. Still, we commit to this amount of work. It is
> however far more likely that we will deliver more, since our average
> amount of stories delivered in an iteration was that. We have never
> delivered more that this other amount of stories in an iteration, so
> it is unlikely that we will exceed that. Can you, as our valued
> customer, lay all these stories in descending order of value, for you
> as you now see it, so we can all know which next story to take should
> the likelyhood appear that we finish early?"
>
> You can substitue the least amount of stories ever for any number you
> find resonable or fair.
>
> This is how we've been doing it up till now;
>
> We'd like to take our average storypoint delivered minus 2 standard
> deviations. In a classic bell-curve, that covers over 95% of the
> cases.
>
> We make a release plan that commits to only that amount of
> storypoints, and update the plan during the planning game to reflect
> reality more and more.
>
> Once every 20 or so iterations something goes wrong. We've build up
> enough trust-credit with the customer in the past 19 iterations that I
> believe he'll be adamant when we say: "Listen, something went wrong.
> Will you work with us because we really want to get back on track as
> fast as possible?" If he's not adamant, we could take out the original
> release plan and say: "Look, this is how far ahead we are on the
> original scedule, cut us some slack..."
>
> Why not solve structural problems structural, and incidental problems
> incidental?
>
> Why not face the customer with respect and courage?
>
> I do love the respect value, glad it made it in there.
>
> Cheers, Marko
>
> --
> Met vriendelijke groet,
>
> Marko van der Puil - marko-***@public.gmane.org - http://www.brains4all.com
> Brains4All B.V. - Smart Internet Solutions - Postbus 14 -
> 4493 ZG - Kamperland
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>

[Nigel Thorne]

I have heard reports from long standing XP teams that the constant
rythm of week in, week out, iteration after iteration, engaging
concentrated effort in delivering valuable tested software gets really
tiring. I can understand that. Maybe building a low stress porting
into the end of each itteration helps releave this. Letting the teams
take a breath before the next iteration? Is this where slack fits in?
Do teams really need this?

You mentioned using the slack to get some the technical tasks done
like automation. In traditional time management I believe these would
to be classified as the "important non-urgent" tasks. "When do you
stop and sharpen the blade?" Once a week sounds like a reasonable
frequency to attend to such duties. Is this what you intended by
Slack?

Maybe I'll re-read the practice again. I feel like I am missing the point.

Cheers
Nigel

On Fri, 11 Mar 2005 02:05:54 -0800, Kent Beck <kentb-***@public.gmane.org> wrote:
> Marko,
>
> It seems to me that this whole thread has gone off the rails. I'll try to
> recap what I think everyone agrees on and then perhaps we can continue from
> there. Everyone agrees that we should create as much value as possible.
> Arguments of the form, "...but if you could do something more valuable, why
> wouldn't you do that?" are not likely to be fair readings of someone else's
> ideas.
>
> Slack is not motivated by fear, not for me, unless it is the fear that I
> will once again fall into the trap of thinking that if I don't commit
> beyond
> my abilities I will be fired. I am not the only programmer with this
> problem. My practice of slack is primarily motivated by my desire to be a
> trustworthy partner in a business relationship and only commit to what I
> can
> truly deliver.
>
> Part of the value of slack is the "shock absorber" you mention below. Part
> of it is stress relief--it's not good for anyone to go on over-drive all
> day
> every day. Part of it is acknowledging that we don't always know what will
> have the most/least value or take the most/least effort. Sometimes
> something
> that seemed like a minor enhancement, ends up being the most compelling
> piece of the project. Part of it is acknowledging that we as programmers
> have programmer tasks to complete during a development cycle. A good
> example
> of a slack story is tool-smithing, automating some aspect of development.
> These are worth doing, but not at the risk of not delivering business
> functionality. If you are not overcommitted,you will likely have some free
> time here and there. A stack of slack stories are what you reach for at one
> of those times.
>
> Kent Beck
> Three Rivers Institute
>
> > -----Original Message-----
> > From: Marko van der Puil [mailto:marko-***@public.gmane.org]
> > Sent: Thursday, March 10, 2005 3:35 PM
> > To: xpbookdiscussiongroup-***@public.gmane.org
> > Subject: Re: Re[2]: [xpe2e] Planning game confusion
> >
> >
> > > > It seems to me Doug is the only one getting the idea:
> >
> > I didn't realise this was a flame indicator, my apologies to the list,
> > no harm intended. You are all very intelligent and communicative
> > people and I respect and cherish you for that. My apologies.
> >
> > > Who said you should not talk to your customer during the iteration?
> >
> > No one actually said it, but that was the feeling I was getting while
> > reading this thread.
> >
> > > As far as I understood Kent, his argument is that what also
> > counts is how
> > > the customer reacts. If he reacts negatively to the fact
> > that we didn't
> > > manage to implement the last important story of an
> > iteration, that might
> > > drive us to commit to less important stories at the end of
> > an iteration
> > > (assuming that the customer might react less negatively).
> >
> > Well, I'm having trouble with that kind of commitment. Let me rephrase
> > it as I understand it:
> >
> > Sometimes we (XP developers) overcommit ourselves, or something else
> > bad happens. Therefore sometimes may not be able to finish all of the
> > valuable work we've planned together with the customer. To solve this
> > we are now ALWAYS going to plan to deliver LESS VALUE than we actually
> > know we can. So that when this "sometime" happens, the customer won't
> > be that dissapointed, because he will lose a story of lesser value,
> > instead of a high value one.
> >
> > I can see what might lead to this idea, however I think there are
> > others ways to address this problem.
> >
> > > Using slack for the above reasons doesn't look the most
> > courageously to me.
> > > It feels more like giving in to our fears instead of
> > working on removing the
> > > cause.
> > >
> > > I might be totally wrong, though.
> >
> > I don't think you are. I was wondering how this apparently fear
> > motivated practise got into XP.
> >
> > I've re-read some piece of the XPec2e book today including
> > the bit about Slack.
> > That bit had me worried.
> > Slack is good, fear is not.
> >
> > I also re-read some other bits about the 5 why's, and about planning.
> > Those bits had me feeling good, and left me puzzled.
> >
> > The piece about Slack seems to counterintuative to the other pieces
> > about planning.
> > Still, slack is a planning tool.
> > Slack however seems hard to define.
> > I like the Critical-chain Buffer concept better.
> > A buffer is there to act like a shock absober. When you hit a bump in
> > the road, your car still jumps, and your ride might get a little bit
> > bumpy, but you will not crash from a dump in the road. When there are
> > no bumps in the road, shock-absorbers get you to your destination
> > smoothly and safely.
> >
> > But back to the argument;
> >
> > This low value story slack is not about structural under-estimation.
> > We have velocity to calibrate estimates to reality.
> >
> > It shouldn't be about structural overcommitment, because I think an XP
> > team can self-reflect sufficiently to be able to signal and abandon
> > structural overcommitment.
> >
> > Stories are prioritised according to value. Highest value first. So
> > you always get the highest value story, right?
> >
> > So the stories being dropped are always, by definition, lower in value
> > to the ones realised, right?
> >
> > XP for me is about exellence, about striving and performing at or
> > above the levels you have thought yourself capable of. In my opinion,
> > that includes having the courage and respect to face the customer
> > incidentally and say; I've been bad, I've made a boo-boo. Because of
> > that, you will not get all the value we promised. Now can we sit
> > together and see what we can do about.
> >
> > It's about risk.
> >
> > In the example we've been discussing, it is not clear why the incident
> > has occured that forced us to deliver less value than we promised. I
> > agree with Ilja, that the root-cause of the problem must be adressed.
> >
> > Now, we've determined that this sort of slack is used only to cover
> > incidents, not structural problems. You know you've got a problem
> > when you haven't been able to deliver upon your promises more than 2
> > times in a row. That is a sure trust killer, that is.
> >
> > The problem I'm having with this kind of low-story-slack is that it is
> > introducing a structual inhibitor for delivering the most value
> > possible while trying to adress an issue that is by definition
> > incidental of nature.
> >
> > Why not be completly open and honest:
> >
> > "We can commit to this, because this is the least amount of stories
> > our team has been able to implement in one iteration. There is a
> > remote change that something bas might happen and that we are forced
> > to deliver even less. Still, we commit to this amount of work. It is
> > however far more likely that we will deliver more, since our average
> > amount of stories delivered in an iteration was that. We have never
> > delivered more that this other amount of stories in an iteration, so
> > it is unlikely that we will exceed that. Can you, as our valued
> > customer, lay all these stories in descending order of value, for you
> > as you now see it, so we can all know which next story to take should
> > the likelyhood appear that we finish early?"
> >
> > You can substitue the least amount of stories ever for any number you
> > find resonable or fair.
> >
> > This is how we've been doing it up till now;
> >
> > We'd like to take our average storypoint delivered minus 2 standard
> > deviations. In a classic bell-curve, that covers over 95% of the
> > cases.
> >
> > We make a release plan that commits to only that amount of
> > storypoints, and update the plan during the planning game to reflect
> > reality more and more.
> >
> > Once every 20 or so iterations something goes wrong. We've build up
> > enough trust-credit with the customer in the past 19 iterations that I
> > believe he'll be adamant when we say: "Listen, something went wrong.
> > Will you work with us because we really want to get back on track as
> > fast as possible?" If he's not adamant, we could take out the original
> > release plan and say: "Look, this is how far ahead we are on the
> > original scedule, cut us some slack..."
> >
> > Why not solve structural problems structural, and incidental problems
> > incidental?
> >
> > Why not face the customer with respect and courage?
> >
> > I do love the respect value, glad it made it in there.
> >
> > Cheers, Marko
> >
> > --
> > Met vriendelijke groet,
> >
> > Marko van der Puil - marko-***@public.gmane.org - http://www.brains4all.com
> > Brains4All B.V. - Smart Internet Solutions - Postbus 14 -
> > 4493 ZG - Kamperland
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
> Yahoo! Groups Sponsor
>
> ADVERTISEMENT
>
>
> ________________________________
> Yahoo! Groups Links
>
>
> To visit your group on the web, go to:
> http://groups.yahoo.com/group/xpbookdiscussiongroup/
>
> To unsubscribe from this group, send an email to:
> xpbookdiscussiongroup-unsubscribe-***@public.gmane.org
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


--
Nigel Thorne
Extreme Programmer & Coach
www.nigelthorne.com

[Nigel Thorne]

OK. I have missed the point. The point is "meet your commitments" even
if you have to schedule less work in an iteration to achieve this.
While you have the extra time, use if for whatever is most useful,
whether it's extra features, technical tasks, learning time,
whatever... but make sure you make your commitments first.

Am I getting warmer?

Cheers
Nigel

On Sun, 13 Mar 2005 21:15:04 +1100, Nigel Thorne <nigel.thorne-***@public.gmane.org> wrote:
> I have heard reports from long standing XP teams that the constant
> rythm of week in, week out, iteration after iteration, engaging
> concentrated effort in delivering valuable tested software gets really
> tiring. I can understand that. Maybe building a low stress porting
> into the end of each itteration helps releave this. Letting the teams
> take a breath before the next iteration? Is this where slack fits in?
> Do teams really need this?
>
> You mentioned using the slack to get some the technical tasks done
> like automation. In traditional time management I believe these would
> to be classified as the "important non-urgent" tasks. "When do you
> stop and sharpen the blade?" Once a week sounds like a reasonable
> frequency to attend to such duties. Is this what you intended by
> Slack?
>
> Maybe I'll re-read the practice again. I feel like I am missing the point.
>
> Cheers
> Nigel
>
> On Fri, 11 Mar 2005 02:05:54 -0800, Kent Beck <kentb-***@public.gmane.org> wrote:
> > Marko,
> >
> > It seems to me that this whole thread has gone off the rails. I'll try to
> > recap what I think everyone agrees on and then perhaps we can continue from
> > there. Everyone agrees that we should create as much value as possible.
> > Arguments of the form, "...but if you could do something more valuable, why
> > wouldn't you do that?" are not likely to be fair readings of someone else's
> > ideas.
> >
> > Slack is not motivated by fear, not for me, unless it is the fear that I
> > will once again fall into the trap of thinking that if I don't commit
> > beyond
> > my abilities I will be fired. I am not the only programmer with this
> > problem. My practice of slack is primarily motivated by my desire to be a
> > trustworthy partner in a business relationship and only commit to what I
> > can
> > truly deliver.
> >
> > Part of the value of slack is the "shock absorber" you mention below. Part
> > of it is stress relief--it's not good for anyone to go on over-drive all
> > day
> > every day. Part of it is acknowledging that we don't always know what will
> > have the most/least value or take the most/least effort. Sometimes
> > something
> > that seemed like a minor enhancement, ends up being the most compelling
> > piece of the project. Part of it is acknowledging that we as programmers
> > have programmer tasks to complete during a development cycle. A good
> > example
> > of a slack story is tool-smithing, automating some aspect of development.
> > These are worth doing, but not at the risk of not delivering business
> > functionality. If you are not overcommitted,you will likely have some free
> > time here and there. A stack of slack stories are what you reach for at one
> > of those times.
> >
> > Kent Beck
> > Three Rivers Institute
> >
> > > -----Original Message-----
> > > From: Marko van der Puil [mailto:marko-***@public.gmane.org]
> > > Sent: Thursday, March 10, 2005 3:35 PM
> > > To: xpbookdiscussiongroup-***@public.gmane.org
> > > Subject: Re: Re[2]: [xpe2e] Planning game confusion
> > >
> > >
> > > > > It seems to me Doug is the only one getting the idea:
> > >
> > > I didn't realise this was a flame indicator, my apologies to the list,
> > > no harm intended. You are all very intelligent and communicative
> > > people and I respect and cherish you for that. My apologies.
> > >
> > > > Who said you should not talk to your customer during the iteration?
> > >
> > > No one actually said it, but that was the feeling I was getting while
> > > reading this thread.
> > >
> > > > As far as I understood Kent, his argument is that what also
> > > counts is how
> > > > the customer reacts. If he reacts negatively to the fact
> > > that we didn't
> > > > manage to implement the last important story of an
> > > iteration, that might
> > > > drive us to commit to less important stories at the end of
> > > an iteration
> > > > (assuming that the customer might react less negatively).
> > >
> > > Well, I'm having trouble with that kind of commitment. Let me rephrase
> > > it as I understand it:
> > >
> > > Sometimes we (XP developers) overcommit ourselves, or something else
> > > bad happens. Therefore sometimes may not be able to finish all of the
> > > valuable work we've planned together with the customer. To solve this
> > > we are now ALWAYS going to plan to deliver LESS VALUE than we actually
> > > know we can. So that when this "sometime" happens, the customer won't
> > > be that dissapointed, because he will lose a story of lesser value,
> > > instead of a high value one.
> > >
> > > I can see what might lead to this idea, however I think there are
> > > others ways to address this problem.
> > >
> > > > Using slack for the above reasons doesn't look the most
> > > courageously to me.
> > > > It feels more like giving in to our fears instead of
> > > working on removing the
> > > > cause.
> > > >
> > > > I might be totally wrong, though.
> > >
> > > I don't think you are. I was wondering how this apparently fear
> > > motivated practise got into XP.
> > >
> > > I've re-read some piece of the XPec2e book today including
> > > the bit about Slack.
> > > That bit had me worried.
> > > Slack is good, fear is not.
> > >
> > > I also re-read some other bits about the 5 why's, and about planning.
> > > Those bits had me feeling good, and left me puzzled.
> > >
> > > The piece about Slack seems to counterintuative to the other pieces
> > > about planning.
> > > Still, slack is a planning tool.
> > > Slack however seems hard to define.
> > > I like the Critical-chain Buffer concept better.
> > > A buffer is there to act like a shock absober. When you hit a bump in
> > > the road, your car still jumps, and your ride might get a little bit
> > > bumpy, but you will not crash from a dump in the road. When there are
> > > no bumps in the road, shock-absorbers get you to your destination
> > > smoothly and safely.
> > >
> > > But back to the argument;
> > >
> > > This low value story slack is not about structural under-estimation.
> > > We have velocity to calibrate estimates to reality.
> > >
> > > It shouldn't be about structural overcommitment, because I think an XP
> > > team can self-reflect sufficiently to be able to signal and abandon
> > > structural overcommitment.
> > >
> > > Stories are prioritised according to value. Highest value first. So
> > > you always get the highest value story, right?
> > >
> > > So the stories being dropped are always, by definition, lower in value
> > > to the ones realised, right?
> > >
> > > XP for me is about exellence, about striving and performing at or
> > > above the levels you have thought yourself capable of. In my opinion,
> > > that includes having the courage and respect to face the customer
> > > incidentally and say; I've been bad, I've made a boo-boo. Because of
> > > that, you will not get all the value we promised. Now can we sit
> > > together and see what we can do about.
> > >
> > > It's about risk.
> > >
> > > In the example we've been discussing, it is not clear why the incident
> > > has occured that forced us to deliver less value than we promised. I
> > > agree with Ilja, that the root-cause of the problem must be adressed.
> > >
> > > Now, we've determined that this sort of slack is used only to cover
> > > incidents, not structural problems. You know you've got a problem
> > > when you haven't been able to deliver upon your promises more than 2
> > > times in a row. That is a sure trust killer, that is.
> > >
> > > The problem I'm having with this kind of low-story-slack is that it is
> > > introducing a structual inhibitor for delivering the most value
> > > possible while trying to adress an issue that is by definition
> > > incidental of nature.
> > >
> > > Why not be completly open and honest:
> > >
> > > "We can commit to this, because this is the least amount of stories
> > > our team has been able to implement in one iteration. There is a
> > > remote change that something bas might happen and that we are forced
> > > to deliver even less. Still, we commit to this amount of work. It is
> > > however far more likely that we will deliver more, since our average
> > > amount of stories delivered in an iteration was that. We have never
> > > delivered more that this other amount of stories in an iteration, so
> > > it is unlikely that we will exceed that. Can you, as our valued
> > > customer, lay all these stories in descending order of value, for you
> > > as you now see it, so we can all know which next story to take should
> > > the likelyhood appear that we finish early?"
> > >
> > > You can substitue the least amount of stories ever for any number you
> > > find resonable or fair.
> > >
> > > This is how we've been doing it up till now;
> > >
> > > We'd like to take our average storypoint delivered minus 2 standard
> > > deviations. In a classic bell-curve, that covers over 95% of the
> > > cases.
> > >
> > > We make a release plan that commits to only that amount of
> > > storypoints, and update the plan during the planning game to reflect
> > > reality more and more.
> > >
> > > Once every 20 or so iterations something goes wrong. We've build up
> > > enough trust-credit with the customer in the past 19 iterations that I
> > > believe he'll be adamant when we say: "Listen, something went wrong.
> > > Will you work with us because we really want to get back on track as
> > > fast as possible?" If he's not adamant, we could take out the original
> > > release plan and say: "Look, this is how far ahead we are on the
> > > original scedule, cut us some slack..."
> > >
> > > Why not solve structural problems structural, and incidental problems
> > > incidental?
> > >
> > > Why not face the customer with respect and courage?
> > >
> > > I do love the respect value, glad it made it in there.
> > >
> > > Cheers, Marko
> > >
> > > --
> > > Met vriendelijke groet,
> > >
> > > Marko van der Puil - marko-***@public.gmane.org - http://www.brains4all.com
> > > Brains4All B.V. - Smart Internet Solutions - Postbus 14 -
> > > 4493 ZG - Kamperland
> > >
> > >
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> > Yahoo! Groups Sponsor
> >
> > ADVERTISEMENT
> >
> >
> > ________________________________
> > Yahoo! Groups Links
> >
> >
> > To visit your group on the web, go to:
> > http://groups.yahoo.com/group/xpbookdiscussiongroup/
> >
> > To unsubscribe from this group, send an email to:
> > xpbookdiscussiongroup-unsubscribe-***@public.gmane.org
> >
> > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>
> --
> Nigel Thorne
> Extreme Programmer & Coach
> www.nigelthorne.com
>


--
Nigel Thorne
Extreme Programmer & Coach
www.nigelthorne.com

[Ron Jeffries]

On Sunday, March 13, 2005, at 3:27:03 AM, Nigel Thorne wrote:

> OK. I have missed the point. The point is "meet your commitments" even
> if you have to schedule less work in an iteration to achieve this.
> While you have the extra time, use if for whatever is most useful,
> whether it's extra features, technical tasks, learning time,
> whatever... but make sure you make your commitments first.

> Am I getting warmer?

I'm not sure, Nigel. It seems to me that if we wish to schedule
ourselves so as always to meet our commitments, we must invariably
commit to less than we will sometimes be able to accomplish.

Now I can imagine a commitment of the form "Seven stories plus or
minus two", which is met if we do 5-9 stories. But that doesn't
sound like what Kent is espousing. I remain confused.

Ron Jeffries
www.XProgramming.com
Knowledge must come through action;
you can have no test which is not fanciful, save by trial. -- Sophocles

[Kent Beck]

Ron,

Ignoring my advice for the moment, what is your advice to teams about how
much work they should plan and the nature of that plan (e.g. commitment,
promise, best guess, just a plan,...)?

Kent Beck
Three Rivers Institute

> -----Original Message-----
> From: Ron Jeffries [mailto:ronjeffries-***@public.gmane.org]
> Sent: Sunday, March 13, 2005 2:47 AM
> To: xpbookdiscussiongroup-***@public.gmane.org
> Subject: Re: [xpe2e] Planning game confusion
>
>
> On Sunday, March 13, 2005, at 3:27:03 AM, Nigel Thorne wrote:
>
> > OK. I have missed the point. The point is "meet your
> commitments" even
> > if you have to schedule less work in an iteration to achieve this.
> > While you have the extra time, use if for whatever is most useful,
> > whether it's extra features, technical tasks, learning time,
> > whatever... but make sure you make your commitments first.
>
> > Am I getting warmer?
>
> I'm not sure, Nigel. It seems to me that if we wish to schedule
> ourselves so as always to meet our commitments, we must invariably
> commit to less than we will sometimes be able to accomplish.
>
> Now I can imagine a commitment of the form "Seven stories plus or
> minus two", which is met if we do 5-9 stories. But that doesn't
> sound like what Kent is espousing. I remain confused.
>
> Ron Jeffries
> www.XProgramming.com
> Knowledge must come through action;
> you can have no test which is not fanciful, save by trial. --
> Sophocles
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>

[Kent Beck]

Nigel,

By George, I think you've got it. Imagine you were able to offer commitment
and accountability to your customers. Could you sell that? Could you enjoy
doing it?

Kent Beck
Three Rivers Institute

> -----Original Message-----
> From: Nigel Thorne [mailto:nigel.thorne-***@public.gmane.org]
> Sent: Sunday, March 13, 2005 2:27 AM
> To: xpbookdiscussiongroup-***@public.gmane.org
> Subject: Re: Re[2]: [xpe2e] Planning game confusion
>
>
> OK. I have missed the point. The point is "meet your commitments" even
> if you have to schedule less work in an iteration to achieve this.
> While you have the extra time, use if for whatever is most useful,
> whether it's extra features, technical tasks, learning time,
> whatever... but make sure you make your commitments first.
>
> Am I getting warmer?
>
> Cheers
> Nigel
>
> On Sun, 13 Mar 2005 21:15:04 +1100, Nigel Thorne
> <nigel.thorne-***@public.gmane.org> wrote:
> > I have heard reports from long standing XP teams that the constant
> > rythm of week in, week out, iteration after iteration, engaging
> > concentrated effort in delivering valuable tested software
> gets really
> > tiring. I can understand that. Maybe building a low stress porting
> > into the end of each itteration helps releave this. Letting
> the teams
> > take a breath before the next iteration? Is this where
> slack fits in?
> > Do teams really need this?
> >
> > You mentioned using the slack to get some the technical tasks done
> > like automation. In traditional time management I believe
> these would
> > to be classified as the "important non-urgent" tasks. "When do you
> > stop and sharpen the blade?" Once a week sounds like a reasonable
> > frequency to attend to such duties. Is this what you intended by
> > Slack?
> >
> > Maybe I'll re-read the practice again. I feel like I am
> missing the point.
> >
> > Cheers
> > Nigel
> >
> > On Fri, 11 Mar 2005 02:05:54 -0800, Kent Beck
> <kentb-***@public.gmane.org> wrote:
> > > Marko,
> > >
> > > It seems to me that this whole thread has gone off the
> rails. I'll try to
> > > recap what I think everyone agrees on and then perhaps
> we can continue from
> > > there. Everyone agrees that we should create as much
> value as possible.
> > > Arguments of the form, "...but if you could do something
> more valuable, why
> > > wouldn't you do that?" are not likely to be fair
> readings of someone else's
> > > ideas.
> > >
> > > Slack is not motivated by fear, not for me, unless it is
> the fear that I
> > > will once again fall into the trap of thinking that if I
> don't commit
> > > beyond
> > > my abilities I will be fired. I am not the only
> programmer with this
> > > problem. My practice of slack is primarily motivated by
> my desire to be a
> > > trustworthy partner in a business relationship and only
> commit to what I
> > > can
> > > truly deliver.
> > >
> > > Part of the value of slack is the "shock absorber" you
> mention below. Part
> > > of it is stress relief--it's not good for anyone to go
> on over-drive all
> > > day
> > > every day. Part of it is acknowledging that we don't
> always know what will
> > > have the most/least value or take the most/least effort.
> Sometimes
> > > something
> > > that seemed like a minor enhancement, ends up being the
> most compelling
> > > piece of the project. Part of it is acknowledging that
> we as programmers
> > > have programmer tasks to complete during a development
> cycle. A good
> > > example
> > > of a slack story is tool-smithing, automating some
> aspect of development.
> > > These are worth doing, but not at the risk of not
> delivering business
> > > functionality. If you are not overcommitted,you will
> likely have some free
> > > time here and there. A stack of slack stories are what
> you reach for at one
> > > of those times.
> > >
> > > Kent Beck
> > > Three Rivers Institute
> > >
> > > > -----Original Message-----
> > > > From: Marko van der Puil [mailto:marko-***@public.gmane.org]
> > > > Sent: Thursday, March 10, 2005 3:35 PM
> > > > To: xpbookdiscussiongroup-***@public.gmane.org
> > > > Subject: Re: Re[2]: [xpe2e] Planning game confusion
> > > >
> > > >
> > > > > > It seems to me Doug is the only one getting the idea:
> > > >
> > > > I didn't realise this was a flame indicator, my
> apologies to the list,
> > > > no harm intended. You are all very intelligent and
> communicative
> > > > people and I respect and cherish you for that. My apologies.
> > > >
> > > > > Who said you should not talk to your customer during
> the iteration?
> > > >
> > > > No one actually said it, but that was the feeling I
> was getting while
> > > > reading this thread.
> > > >
> > > > > As far as I understood Kent, his argument is that what also
> > > > counts is how
> > > > > the customer reacts. If he reacts negatively to the fact
> > > > that we didn't
> > > > > manage to implement the last important story of an
> > > > iteration, that might
> > > > > drive us to commit to less important stories at the end of
> > > > an iteration
> > > > > (assuming that the customer might react less negatively).
> > > >
> > > > Well, I'm having trouble with that kind of commitment.
> Let me rephrase
> > > > it as I understand it:
> > > >
> > > > Sometimes we (XP developers) overcommit ourselves, or
> something else
> > > > bad happens. Therefore sometimes may not be able to
> finish all of the
> > > > valuable work we've planned together with the
> customer. To solve this
> > > > we are now ALWAYS going to plan to deliver LESS VALUE
> than we actually
> > > > know we can. So that when this "sometime" happens, the
> customer won't
> > > > be that dissapointed, because he will lose a story of
> lesser value,
> > > > instead of a high value one.
> > > >
> > > > I can see what might lead to this idea, however I
> think there are
> > > > others ways to address this problem.
> > > >
> > > > > Using slack for the above reasons doesn't look the most
> > > > courageously to me.
> > > > > It feels more like giving in to our fears instead of
> > > > working on removing the
> > > > > cause.
> > > > >
> > > > > I might be totally wrong, though.
> > > >
> > > > I don't think you are. I was wondering how this apparently fear
> > > > motivated practise got into XP.
> > > >
> > > > I've re-read some piece of the XPec2e book today including
> > > > the bit about Slack.
> > > > That bit had me worried.
> > > > Slack is good, fear is not.
> > > >
> > > > I also re-read some other bits about the 5 why's, and
> about planning.
> > > > Those bits had me feeling good, and left me puzzled.
> > > >
> > > > The piece about Slack seems to counterintuative to the
> other pieces
> > > > about planning.
> > > > Still, slack is a planning tool.
> > > > Slack however seems hard to define.
> > > > I like the Critical-chain Buffer concept better.
> > > > A buffer is there to act like a shock absober. When
> you hit a bump in
> > > > the road, your car still jumps, and your ride might
> get a little bit
> > > > bumpy, but you will not crash from a dump in the road.
> When there are
> > > > no bumps in the road, shock-absorbers get you to your
> destination
> > > > smoothly and safely.
> > > >
> > > > But back to the argument;
> > > >
> > > > This low value story slack is not about structural
> under-estimation.
> > > > We have velocity to calibrate estimates to reality.
> > > >
> > > > It shouldn't be about structural overcommitment,
> because I think an XP
> > > > team can self-reflect sufficiently to be able to
> signal and abandon
> > > > structural overcommitment.
> > > >
> > > > Stories are prioritised according to value. Highest
> value first. So
> > > > you always get the highest value story, right?
> > > >
> > > > So the stories being dropped are always, by
> definition, lower in value
> > > > to the ones realised, right?
> > > >
> > > > XP for me is about exellence, about striving and
> performing at or
> > > > above the levels you have thought yourself capable of.
> In my opinion,
> > > > that includes having the courage and respect to face
> the customer
> > > > incidentally and say; I've been bad, I've made a
> boo-boo. Because of
> > > > that, you will not get all the value we promised. Now
> can we sit
> > > > together and see what we can do about.
> > > >
> > > > It's about risk.
> > > >
> > > > In the example we've been discussing, it is not clear
> why the incident
> > > > has occured that forced us to deliver less value than
> we promised. I
> > > > agree with Ilja, that the root-cause of the problem
> must be adressed.
> > > >
> > > > Now, we've determined that this sort of slack is used
> only to cover
> > > > incidents, not structural problems. You know you've
> got a problem
> > > > when you haven't been able to deliver upon your
> promises more than 2
> > > > times in a row. That is a sure trust killer, that is.
> > > >
> > > > The problem I'm having with this kind of
> low-story-slack is that it is
> > > > introducing a structual inhibitor for delivering the most value
> > > > possible while trying to adress an issue that is by definition
> > > > incidental of nature.
> > > >
> > > > Why not be completly open and honest:
> > > >
> > > > "We can commit to this, because this is the least
> amount of stories
> > > > our team has been able to implement in one iteration.
> There is a
> > > > remote change that something bas might happen and that
> we are forced
> > > > to deliver even less. Still, we commit to this amount
> of work. It is
> > > > however far more likely that we will deliver more,
> since our average
> > > > amount of stories delivered in an iteration was that.
> We have never
> > > > delivered more that this other amount of stories in an
> iteration, so
> > > > it is unlikely that we will exceed that. Can you, as our valued
> > > > customer, lay all these stories in descending order of
> value, for you
> > > > as you now see it, so we can all know which next story
> to take should
> > > > the likelyhood appear that we finish early?"
> > > >
> > > > You can substitue the least amount of stories ever for
> any number you
> > > > find resonable or fair.
> > > >
> > > > This is how we've been doing it up till now;
> > > >
> > > > We'd like to take our average storypoint delivered
> minus 2 standard
> > > > deviations. In a classic bell-curve, that covers over
> 95% of the
> > > > cases.
> > > >
> > > > We make a release plan that commits to only that amount of
> > > > storypoints, and update the plan during the planning
> game to reflect
> > > > reality more and more.
> > > >
> > > > Once every 20 or so iterations something goes wrong.
> We've build up
> > > > enough trust-credit with the customer in the past 19
> iterations that I
> > > > believe he'll be adamant when we say: "Listen,
> something went wrong.
> > > > Will you work with us because we really want to get
> back on track as
> > > > fast as possible?" If he's not adamant, we could take
> out the original
> > > > release plan and say: "Look, this is how far ahead we
> are on the
> > > > original scedule, cut us some slack..."
> > > >
> > > > Why not solve structural problems structural, and
> incidental problems
> > > > incidental?
> > > >
> > > > Why not face the customer with respect and courage?
> > > >
> > > > I do love the respect value, glad it made it in there.
> > > >
> > > > Cheers, Marko
> > > >
> > > > --
> > > > Met vriendelijke groet,
> > > >
> > > > Marko van der Puil - marko-***@public.gmane.org -
> http://www.brains4all.com
> > > > Brains4All B.V. - Smart Internet Solutions - Postbus 14 -
> > > > 4493 ZG - Kamperland
> > > >
> > > >
> > > >
> > > > Yahoo! Groups Links
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > > Yahoo! Groups Sponsor
> > >
> > > ADVERTISEMENT
> > >
> > >
> > > ________________________________
> > > Yahoo! Groups Links
> > >
> > >
> > > To visit your group on the web, go to:
> > > http://groups.yahoo.com/group/xpbookdiscussiongroup/
> > >
> > > To unsubscribe from this group, send an email to:
> > > xpbookdiscussiongroup-unsubscribe-***@public.gmane.org
> > >
> > > Your use of Yahoo! Groups is subject to the Yahoo! Terms
> of Service.
> >
> > --
> > Nigel Thorne
> > Extreme Programmer & Coach
> > www.nigelthorne.com
> >
>
>
> --
> Nigel Thorne
> Extreme Programmer & Coach
> www.nigelthorne.com
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>

[Joel Shellman]

On a project I was on once, we just did gold stories. One advantage to
this is that we would always plan a couple extra stories above our
velocity just in case we got to them. And it gave us a nice headstart
on the next iteration plan because usually the left over stories would
be what we would work on first in the next iteration.

On a related topic, I'd like to suggest it would be useful to see how
certain principles affect the team internally:

> A common expectation is that employees sometimes underdeliver but never
> overdeliver.

What are you communicating to the developers if you have that
expectation? This expectation shows lack of trust, shows lack of faith
that there is buy-in from the developers, etc. For a team of good
solid developers who have passion for what they do and desire to
excel, this expectation would be demoralizing. Said another way, any
team for which this isn't demoralizing is most likely already
demoralized anyway.

On the flip side, if you were referring to the fact that many
developers routinely underestimate effort for a given task, there's
some truth there--but that should be stated quite differently and
handled differently--velocity/YW already deals with that issue.

> Well put. Of course we aren't better than we actually are, although
> many people schedule that way: take the best possible case, call it your
> expectation, then commit to it. The only way to succeed doing that is
> to make a mistake and somehow underestimate velocity.

And this would be unsustainable and would also be very demoralizing.
Developers soon realize that by working hard and well, all they do is
raise the bar for themselves to unrealistic and unsustainable levels.

> Another common mistake is to take the average and commit to that. The
> average is a reasonable expectation but it's not a reasonable thing to
> commit to because about half the time you fall short. On the other
> hand, at most companies in this industry, falling short only half of the
> time would be a good outcome .

I'm actually a little confused by this discussion. The idea of
velocity is it becomes a statistical approximation of how many units
the team can accomplish in an iteration. It cannot be a definitive
prediction on how much will be accomplished in a specific iteration.
There are way way too many variables for that. If "commitment" is
absolutely necessary to the customer, one could use an appropriate
statistical model to determine how much would be done with 95% (or
whatever you're comfortable with) surety. Personally, I would prefer
to explain that velocity is the middle of a bell curve-like function
and that we'll accomplish somewhere around that. If they can't handle
that, then they need some reality education anyway since the real
world isn't predictable on that scale. If it was, we wouldn't need
agile methodologies now would we?

Joel Shellman

[Tim King]

Joel Shellman wrote:
>>Another common mistake is to take the average and commit to that. The
>>average is a reasonable expectation but it's not a reasonable thing to
>>commit to because about half the time you fall short. On the other
>>hand, at most companies in this industry, falling short only half of the
>>time would be a good outcome .
>
> I'm actually a little confused by this discussion. The idea of
> velocity is it becomes a statistical approximation of how many units
> the team can accomplish in an iteration... If "commitment" is
> absolutely necessary to the customer, one could use an appropriate
> statistical model to determine how much would be done with 95%...
> surety. Personally, I would prefer to explain that velocity is the
> middle of a bell curve-like function...

My understanding is that tasks complete with a Log-Normal probability.
http://mathworld.wolfram.com/LogNormalDistribution.html That is, there's
an initial hump in the curve and then a long tail.

The median (50% chance of completion) point is at the hump of the curve,
whereas the mean (average) point is later in the curve. So if you
compute the mean of how long each story-point takes to complete, you'll
actually schedule a longer time per story-point than the 50'th percentile.

Some scheduling systems (like Critical Chain) estimate at 50%
probability of completion. If you push the estimate out to 90%, it's
easier to procrastinate, to spend more than the optimum time polishing
already finished work, or otherwise cause the work to expand to fill up
the alotted time better. If you estimate at 50%, that number becomes a
real, measured indication of what you can actually expect from yourself.

A whole string of tasks estimated at 50% will have an accumulated
certainty of no more than 50%. That is, the whole group will overrun at
least half the time. In order to compenstate for the high probability of
overruns, Critical Chain adds buffers just before key, fixed points in
the schedule. These buffers change the <50% completion probability into
a higher probability of completion.

An interesting property of Log-Normal tasks is that if you have a long
string of stories, if you can truly work on them one right after the
other with no waiting, the whole bunch of stories will complete with 90%
certainty earlier than the sum of all the 90%-certainty points of the
individual stories. That is, the more story-points you include in an
estimate, the more confident you can be about your estimate. And the
more confident you need to be, the more pronounced the cumulative
effect. This is only true if you do these stories one right after the
other, with no blocking, waiting for a developer to become available.

Maybe this is one of the advantages of shared code ownership and
pair-programming. With shared code ownership, you seldom have a string
of stories that must be handled by a particular team member, so if one
developer is progressing more slowly than expected, others can take up
the slack. With pair-programming, this can occur even at the microcosmic
level, in real-time interation between members of the pair.

(Note, however, I am not a statistician.)

-TimK
--
J. Timothy King ..team-oriented..object-oriented..Agile..
www.jtse.com ..C++..Perl..Java..assembly..embedded.systems..

[Dave Rooney]

> -----Original Message-----
> From: Kent Beck [mailto:kentb-***@public.gmane.org]
> Sent: Wednesday, March 02, 2005 3:02 PM
> To: xpbookdiscussiongroup-***@public.gmane.org
> Subject: RE: [xpe2e] Planning game confusion
>

[snip]

> Something that bothers me about this whole discussion is
> people's apparent need to wring every last iota of value out
> of development.

Our team currently goes out for an extended lunch almost every Friday.
Things such as builds that are broken overnight are considered "beerable
offences", payable as a round on Friday. Almost everyone on the team
participates (especially after a broken build!), and it's a great time
for the team to just hang out, kick back and laugh about things.

This 'practice' (or possibly a 'principle'), was initiated by our
manager and does a great job IMHO of keeping the team together.

I suppose this could be considered part of Slack. Regardless, it has a
very definite, positive influence on our team.

Dave Rooney
Mayford Technologies
http://www.mayford.ca

[William Pietri]

On Fri, 2005-03-11 at 02:05 -0800, Kent Beck wrote:
> A good example of a slack story is tool-smithing, automating some
> aspect of development. These are worth doing, but not at the risk of
> not delivering business functionality.

Hi, Kent. Do you feel that all slack stories are things that only the
programmers care about? Or do you feel that low-value business stories
are also the kinds of "silver" stories that one should schedule as
slack?

Thanks,

William

--
William Pietri <william-***@public.gmane.org>

[Kent Beck]

William,

The bigger question is, "What do you do when you've finished the committed
items and you have time left over?" There are some obvious dysfunctions,
like just wasting time posting on mailing lists and such :-) But there are
many ways to contribute opportunistic value--write a programming tool, try
out new technology,

> -----Original Message-----
> From: William Pietri [mailto:william-***@public.gmane.org]
> Sent: Friday, March 11, 2005 9:12 AM
> To: xpbookdiscussiongroup-***@public.gmane.org
> Subject: RE: Re[2]: [xpe2e] Planning game confusion
>
>
> On Fri, 2005-03-11 at 02:05 -0800, Kent Beck wrote:
> > A good example of a slack story is tool-smithing, automating some
> > aspect of development. These are worth doing, but not at the risk of
> > not delivering business functionality.
>
> Hi, Kent. Do you feel that all slack stories are things that only the
> programmers care about? Or do you feel that low-value business stories
> are also the kinds of "silver" stories that one should schedule as
> slack?

[Luiz Esmiralha]

On Mon, 14 Mar 2005 08:31:58 -0800, Kent Beck <kentb-***@public.gmane.org> wrote:
> William,
>
> The bigger question is, "What do you do when you've finished the committed
> items and you have time left over?" There are some obvious dysfunctions,
> like just wasting time posting on mailing lists and such :-) But there are
> many ways to contribute opportunistic value--write a programming tool, try
> out new technology,
>

Hmm, I would try to schedule an additional story if I had enough time
left for that. Otherwise, I would spend it on geek activities, like
toolsmithing, concept proofs, furniture reorganization, room materials
shopping....

[William Pietri]

On Mon, 2005-03-14 at 08:31 -0800, Kent Beck wrote:
> On Fri, 2005-03-11 at 02:05 -0800, Kent Beck wrote:
> > > A good example of a slack story is tool-smithing, automating some
> > > aspect of development. These are worth doing, but not at the risk of
> > > not delivering business functionality.
> >
> > Hi, Kent. Do you feel that all slack stories are things that only the
> > programmers care about? Or do you feel that low-value business stories
> > are also the kinds of "silver" stories that one should schedule as
> > slack?
>
> The bigger question is, "What do you do when you've finished the committed
> items and you have time left over?" There are some obvious dysfunctions,
> like just wasting time posting on mailing lists and such :-) But there are
> many ways to contribute opportunistic value--write a programming tool, try
> out new technology,

I'd certainly agree with this. The distinction I was looking for was hit
more exactly by another poster when they talked about important vs
urgent. I personally like to use slack time for things that the
programmers think important but not urgent, which are almost always
things that the XP Customer doesn't know much about and generally
doesn't even want to know about.

That pattern has worked well for me, but it's very different than the 8
gold + 4 silver pattern that has been discussed. I am looking to find
out which one you were advocating.

Thanks,

William


--
William Pietri <william-***@public.gmane.org>

[Shane Mingins]

--- "J. B. Rainsberger" <jbrains-bJEeYj9oJeDQT0dZR+***@public.gmane.org> wrote:
> Perhaps. I think we have to recognize when we don't
> yet have the trust
> of the customer (and her bosses up the chain) and
> perhaps underpromise
> until we gain some of that trust.

Is that perhaps a dangerous game? I just can't help
thinking that being dishonest is not a way to gain
trust.

And if you think you can deliver 8 stories but tell
the customer 5 ... is that being dishonest?

Shane

--
"And great minds don't think alike. If they did, the
patent office would only have about fifty inventions."
- Wally (from Dilbert)







__________________________________
Do you Yahoo!?
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250

[Luiz Esmiralha]

On Wed, 16 Mar 2005 09:35:06 -0800 (PST), Shane Mingins
<shanemingins-/***@public.gmane.org> wrote:
>
> --- "J. B. Rainsberger" <jbrains-bJEeYj9oJeDQT0dZR+***@public.gmane.org> wrote:
> > Perhaps. I think we have to recognize when we don't
> > yet have the trust
> > of the customer (and her bosses up the chain) and
> > perhaps underpromise
> > until we gain some of that trust.
>
> Is that perhaps a dangerous game? I just can't help
> thinking that being dishonest is not a way to gain
> trust.
>
> And if you think you can deliver 8 stories but tell
> the customer 5 ... is that being dishonest?
>

It should be clear to the customer that we use Slack as a practice.
You just can't hope to achieve trust by hiding something from the
customer.

[William Pietri]

On Wed, 2005-03-16 at 14:54 -0300, Luiz Esmiralha wrote:
> It should be clear to the customer that we use Slack as a practice.
> You just can't hope to achieve trust by hiding something from the
> customer.

I wonder if it's necessary to declare it in that way. When teams pick
stories for the week, I encourage them to be 80% certain that they will
finish in time, rather than the 50% chance that many people naturally
use, or the 1% chance that most bad schedulers use.

That kind of approach will give you some slack most iterations. And
occasionally you get an iteration that makes you sweat a little, which I
think is also good for people.

William

--
William Pietri <william-***@public.gmane.org>

[BenAveling]

Shane Mingins wrote:

>And if you think you can deliver 8 stories but tell
>the customer 5 ... is that being dishonest?
>
>

Hi Shane,

Are you talking about telling the customer:
a) "We can deliver 5 stories"
b) "We can only deliver 5 stories"
or
c) "We can deliver 8 stories"

None of those statements are completely true or false.

But one of them is truer than the other two.

Regards, Ben

[Ron Jeffries]

On Wednesday, March 16, 2005, at 10:35:06 AM, Shane Mingins wrote:

> --- "J. B. Rainsberger" <jbrains-bJEeYj9oJeDQT0dZR+***@public.gmane.org> wrote:
>> Perhaps. I think we have to recognize when we don't
>> yet have the trust
>> of the customer (and her bosses up the chain) and
>> perhaps underpromise
>> until we gain some of that trust.

> Is that perhaps a dangerous game? I just can't help
> thinking that being dishonest is not a way to gain
> trust.

> And if you think you can deliver 8 stories but tell
> the customer 5 ... is that being dishonest?

I share the concern. My plan is to take Bill Caputo's longer note as
a basis for a thoughtful reply.

Ron Jeffries
www.XProgramming.com
Inigo Montoya: You are wonderful!
Man in Black: Thank you. I have worked hard to become so.

[Shane Mingins]

--- BenAveling <bena-***@public.gmane.org> wrote:
>
> Shane Mingins wrote:
>
> >And if you think you can deliver 8 stories but tell
> >the customer 5 ... is that being dishonest?
> >
> >
>
> Hi Shane,
>
> Are you talking about telling the customer:
> a) "We can deliver 5 stories"
> b) "We can only deliver 5 stories"
> or
> c) "We can deliver 8 stories"
>
> None of those statements are completely true or
> false.
>
> But one of them is truer than the other two.

If the team estimates that they can complete 8
stories, does telling the customer they can complete 5
constitute a lie?

Does under-promising and over-delivering create trust
with customers? Or does being as honest as possible
with open and regular conversation create trust (i.e.
part way through we update the customer with "we
cannot deliver the 8 stories, our revised estimate is
7")?

And if yes to both, which is better?

What if the customer learnt that we had deliberately
under-promised and over-delivered. Would that harm
our relationship with them? Perhaps that depends on
what their expectation is.

Thinking of "their expectation" ... if we
under-promise and over-deliver (we commit to 5 stories
and deliver 8) and the customer was quietly (or maybe
outloud) thinking "I thought they should have been
able to deliver 8" ... have we gained trust from the
customer or not?

I am not sure if JB was talking about a situation
where there is distrust to start with or if there is
neither trust or distrust. I read it as being the
latter ... for example a new project where there is
perhaps no history so the customer has no reason to
distrust us, but they also have no reason yet to trust
us. I suppose one could argue that given the general
perception of software development we are likely to be
starting from a place of distrust or wariness.

Cheers
Shane

--
Life is pretty simple: You do some stuff. Most fails.
Some works. You do more of what works. If it works
big, others quickly copy it. Then you do something
else. The trick is the doing something else.
Leonardo da Vinci





__________________________________
Do you Yahoo!?
Make Yahoo! your home page
http://www.yahoo.com/r/hs