Re: Difficulties writing stories

On Mon, 2004-11-22 at 10:53 -0800, kent beck wrote:
> One of the questions I get asked often is what to do when you don't
> know how to write stories the customer cares about. I would like to
> hear from people who have written user-visible stories even when it
> was difficult.

That's a very interesting question. From your other comment in this
thread, I gather that the programmers want to do something but are
having trouble fitting in on a story card. Is that correct?

I think the first thing I always do when confronted with this is to
figure out what the benefits are to the end user. If the answer is
"none", then I don't put it on a story card. Often that means that I
don't do it. When I do it anyhow (e.g., with a big refactoring), from
the customer perspective it ends up as overhead, as lowered velocity.

For those where there's value but I'm just having trouble breaking the
work down in a way that's meaningful to the customer, it's often because
I'm pursuing something that is a development ideal that may not be part
of the customer vocabulary. E.g., scalability, robustness, security,
manageability.

One technique for fixing this is to make sure that the XP customer
really represents all the stakeholders. For a web app, for example, the
operations staff often get ignored in the planning process. Or for a
corporate desktop app, nobody may have asked what the purchaser's IT
staff want out of the product. On a recent project, I just gave the
operations guy a few points to play with, and he came up with some great
requests.

Another is to translate one of those abstract aspects of quality into
something the XP customer does care about. For example, in a recent
project the company hoped that there would eventually be a huge user
base. To us developers, that meant that scalability was very important.
But we could have easily spent all our time solving generic scalability
problems without pushing out any user features, which would have been
terrible.

So our solution was to push it back into the customer's lap. We
eventually got the CEO to describe the maximum load he wanted to be able
to handle at 6 months after launch. This became known as "Load Level A",
and we wrote cards like

      * 1/10% of Load Level A
      * 1% of Load Level A
      * 10% of Load Level A
      * 100% of Load Level A

we were also worried about reliability, and so we wrote cards like

      * System remembers changes after restart
      * Max 6-hour downtime after single-box failure
      * Max 1-hour downtime after single-box failure
      * Max 5-minute downtime after single-box failure
      * User doesn't notice single-box failure

Then the customer shuffled these into the plan as he saw fit.
Interestingly, we did around three months of development with no
persistence at all; everything was just kept hot in RAM and lost when
the power went off. That worked out very well for us; it let people try
things out and do user testing happily. And by the time we actually
needed persistence, it wasn't a theoretical problem; we knew exactly
what we needed to store.

Is that the sort of answer you were looking for, Kent?


William


-- 
William Pietri <william-JnOFOPmZhjNBDgjK7y7TUQ@xxxxxxxxxxxxxxxx>



------------------------ 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
--------------------------------------------------------------------~->