Re: Practice: Weekly Cycle

Ben Hogan wrote:

 > Paul,
 >
 > Is the fact that a story is "comfortably completed" a side-
 > effect of the ordering or priority in the iteration?

Sure it can be.  I think there are a lot of things that can
contribute to a story not being comfortably complete, besides
the story size issue we started with.  Leaving a small, high
risk story until the end of the iteration, even though it may
mathematically fit, could be a pattern that produces
uncomfortably complete stories as well.

 > Iterations are in some ways just a reporting boundary, so
 > the last card in an iteration will often be incomplete, and
 > if you have a larger team, you will have multiple incomplete
 > stories. This is assuming that you have a constant pace, and
 > you don't speed up or slow down to accomodate the iteration
 > boundary. Both speeding up and slowing down seem like a bad
 > idea to me.

Iterations are also an important closure point for the team.
There is a rhythm that develops around the iterations.  I
really don't see teams that have some constant level of
development activity going on, and then, oh, by the way, the
iteration ends today.  There is always something more special
about the iteration boundary.

I think it has to do with the closure of one set of stories,
and the planning of a new set.  And the synchronization point
with the Customer and stakeholders when they get another
(as Scrum calls it) potentially shippable increment.  So, I
see teams running iterations where the pace is not constant
throughout the whole iteration, and the rhythm within the
iteration has rises and dips, and there is a crescendo at the
end.

I agree that the team running up a bunch of overtime hours in
the last days of an iteration in a mad rush to complete the
last few stories can be an anti-pattern.  I like Michael
Feather's pattern of Ease Off as part of a healthy overall
iteration rhythm.  IMHO, there needs to be an awareness of
reaching the closure of the iteration.  Of course not all
iterations are intended to ship, but I think it's healthier
to act as if they all should be able to.

It would be ideal if there were no half-finished stories
hanging around at the end of an iteration, but it happens.
For the purposes of the original comfort metric, I'd say the
team just uses some common sense.  If they know there is a
partially completed story that happened as part of the
"normal" state of things, they don't have to hold that up as
an example of an uncomfortable story.  I would say it's more
useful to look at the stories that the team (or part of the
team) thinks of as being delivered by the iteration and see
how comfortably complete they really are.

The "comfortably complete" metric is intended to be simple,
subjective and imprecise.  Perhaps trying to analyze it and
define it for general use has diminishing returns, and it's
best left up to a team to figure out what to do with it.  I
thought it was a good example of how a simple metric that
takes just a few minutes per iteration to gather could be
very useful for an important process attribute like story
sizing.  Something like:  "Gather the simplest metrics that
could possibly help."  ;-)

Paul
-----
Paul Hodgetts -- CEO, Principal Consultant
phodgetts-5PSskdmeComukZHgTAicrQ@xxxxxxxxxxxxxxxx -- (714) 577-5795

Agile Logic
www.agilelogic.com
1519 E. Chapman Ave. #254 -- Fullerton, CA, USA 92831
Consulting, Coaching, Training -- On-Site & Out-Sourced Development
Agile Processes/Lean/XP/Scrum -- Java/J2EE, C++, OOA/D, UI/IA, XML



------------------------ Yahoo! Groups Sponsor --------------------~--> 
$4.98 domain names from Yahoo!. Register anything.
http://us.click.yahoo.com/Q7_YsB/neXJAA/yQLSAA/nhFolB/TM
--------------------------------------------------------------------~->