Re: Practice: Slack

On Tuesday, December 28, 2004, at 5:59:11 PM, Dale Emery wrote:

>> How do you prevent "minor tasks that can be dropped if you get
>> behind" from being interpreted as broken
>> promises/comittements?

> One possibility is not to promise them or commit to them.  That 
> isn't a foolproof way to prevent people interpreting the change 
> in scope as a broken commitment, but you can sometimes negotiate 
> expectations up front.  "We promise to deliver these three 
> things.  And if we have time, we'll do those other two things, 
> but we can't promise that until we see how these first three 
> things go."

The Scrum process takes an interesting angle. The team /commits/ to
accomplishing the "Sprint Goal". This does not mean a specific set
of "stories", though that would be the ideal solution. But the
commitment is to accomplishing all the functionality that the
stories call for ... somehow.

This is somewhat stronger, it seems to me, than some people's
interpretation of the XP Planning Game. I've seen teams deliver
absolutely nothing in an iteration, and then want to have that be
OK: "Well, I guess our velocity was zero." I think this relates back
to Kent's comments on accountability: it's really not OK to commit
to something and deliver nothing.

Ron Jeffries
www.XProgramming.com
Steering is more important than speed,
in driving and in software development.




------------------------ Yahoo! Groups Sponsor --------------------~--> 
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/nhFolB/TM
--------------------------------------------------------------------~->