Re: Practice: Stories

> Give stories short names in addition to a short prose or graphical
> description. Write the stories on index cards and put them on a
> frequently-passed wall. Figure 6 is a sample card of a story I wish my
> scanner program implemented. Every attempt I've seen to computerize
> stories has failed to provide a fraction of the value of having real
> cards on a real wall. If you need to report progress to other parts of
> the organization in a familiar format, translate the cards into that
> format periodically.

Putting stories on a wall is an example of Visual Workplace, a best practice
(pattern?) strongly promoted by people experienced in Lean
Development/Manufacturing/Thinking (The artist formerly known as
Just-In-Time)

Anyone can step up to a Visual Workplace, see status and what's to be done
next.
--
Do not "computerize stories"!
1. Cards is much easier to hand out during a planning game orf pairs to work
on.
My XP-teams has tought me that the Planning Game is very efficient when it
works as an anthill of parallel work
with a drum beat of sudden silence as some information is broadcasted.
Most of my teams can plan a two-week iteration in about one hour with this
style.
(Of course they have done a demo and showed proof of acceptance tests passed
on the last iterations product before that)

An "anti-pattern" of not using cards as the primary medium was shared at a
presentation I attended recently, by a person from a team that did "XP"

The team did their Planning Game like this:
"We all sit around the customer that has all the stories in an Excel sheet.
His laptop is linked to a projector."
I asked how long each Planning Game took.
"From several hours to a day"
I suggested that they might benefit from at least putting the stories on
cards in between Planning Games.
"Yeah, well we considered that, but no one could find the time to do it"

I later found that they spent another couple of hours every iteration with
signing up individuals for tasks, instead of just letting the next available
take the next engineering task and invite someone to pair.

On the other hand, this team had been happy doing this for at least a year.
(They had taught themselves XP)

/Erik

----------------------------------------------------------------------------
---------------
Compelcon - develops software industry - www.compelcon.se
www.XPseminarie.nu - Hur du lyckas med utvecklingsprojekt NU!

----- Original Message ----- 
From: "Kent Beck" <kentb-ihVZJaRskl1bRRN4PJnoQQ@xxxxxxxxxxxxxxxx>
To: <xpbookdiscussiongroup-hHKSG33TihhbjbujkaE4pw@xxxxxxxxxxxxxxxx>
Sent: Monday, November 15, 2004 7:29 PM
Subject: [xpe2e] Practice: Stories


>
> Plan using units of customer-visible functionality. "Handle five times
> the traffic with the same response time." "Provide a two-click way for
> users to dial frequently used numbers." As soon as a story is written,
> try to estimate the development effort necessary to implement it.
>
> Software development has been steered wrong by the word "requirement",
> defined in the dictionary as "something mandatory or obligatory." The
> word carries a connotation of absolutism and permanence, inhibitors to
> embracing change. And the word "requirement" is just plain wrong. Out of
> 1,000 pages of "requirements", if you deploy a system with the right 20%
> or 10% or even 5%, you will likely realize all of the business benefit
> envisioned for the whole system. So what are the other 80%? Not
> "requirements"; they weren't really mandatory or obligatory.
>
> Early estimation is a key difference between stories and other
> requirements practices. Estimation gives the business and technical
> perspectives a chance to interact, which creates value early, when an
> idea has the most potential. When the team knows the cost of features it
> can split, combine, or extend scope based on what it knows about the
> features' value.
>
> Figure 6: Sample story card
>
> Give stories short names in addition to a short prose or graphical
> description. Write the stories on index cards and put them on a
> frequently-passed wall. Figure 6 is a sample card of a story I wish my
> scanner program implemented. Every attempt I've seen to computerize
> stories has failed to provide a fraction of the value of having real
> cards on a real wall. If you need to report progress to other parts of
> the organization in a familiar format, translate the cards into that
> format periodically.
>
> One feature of XP-style planning is that stories are estimated very
> early in their life. This gets everyone thinking about how to get the
> greatest return from the smallest investment. If someone asks me whether
> I want the Ferrari or the minivan, I choose the Ferrari. It will
> inevitably be more fun. However, as soon as someone says, "Do you want
> the Ferrari for $150,000 or the minivan for $25,000?" I can begin to
> make an informed decision. Adding new constraints like "I need to haul
> five children" or "It has to go 150 miles per hour" clear the picture
> further. There are cases where either decision makes sense. You can't
> make a good decision based on image alone. To choose a car wisely you
> need to know your constraints, both cost and intended use. All other
> things being equal, appeal comes into play.
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>



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