On 1/4/07, Mike Bria <bria526xp@...> wrote:
>
> On 1/4/07, Adam Sroka <adam.sroka@...> wrote:
> >
> > Try to think of a story as a piece of functionality that has value to
> some
> > customer rather than as something that some user does. This is a key
> way
> > that stories differ from traditional use cases.
>
> This is helpful advice. Might you be able to give an example based on
> the scenario I painted?


The below is a bit pedantic and you may already know it, but it may still be
of use to you or to someone else on this list.

The assumption in XP - in all Agile methods for that matter - is that what
we are developing is of value to someone and that this "value to someone" is
driving us to develop it. The key is to identify this "someone" or an
adequate representative and get them to further elucidate the essence of
this value so that we can use technology to realise it. We call this person
(or persons) the customer.

The point I am trying to make is that the *only* way to understand a story
is to think about it in terms of a customer to whom it has value. If you
don't know who that customer is you have much bigger problems than figuring
out what words to write on a card.

Assuming that you do know who your customer is you simply have to agree with
them on what needs to be done to deliver some value incrementally. The
story, the card, the tests, etc. These are all tools that help you to do
that. They are valuable only insofar as they allow you to come to an
agreement as to what must be done and a measure of when that is achieved.

A user can be a customer, but a customer is not necessarily a user. There
are two simple cases: Your customer is a user. e.g. you are building a
webpage that your customer will actually use to accomplish some task. In
this case your stories will look a lot like use cases, because your customer
will derive value directly from her ability to use the application.

Another simple case is that there is no user. e.g. you are building a batch
processing system where the customer derives value from simply having the
system perform without needing to "use" it. This is the case we are dealing
with.

A not-so-simple case that comes up often is where the customer does not in
fact use the system but derives value from the ability of others to use it.
This is the case in nearly all off-the-shelf business software, games,
public web pages, etc. This adds some complexity, but is beyond the scope of
our current discussion.

If we look at the scenario you gave from a use case perspective we would
have something like:

"The System shall write off charges for clinical services when these charges
are less than $10."

This tells us that the actor in our use case is the system itself, and there
is no direct user. However, this doesn't tell us anything about our
customer. Nonetheless, the functionality indicated by this use case is of
value to someone. That someone is your customer.


[Non-text portions of this message have been removed]