RE: [agile-usability] user tasks aren't stories

Hey Jeff, This sounds about right I think. Not sure its a bad thing. A story is a promise for a conversation . During your conversation you work through

Message 1 of 4
, Nov 8, 2004

0 Attachment

Hey Jeff,

This sounds about right I think. Not sure its a bad
thing.

A story is "a promise for a conversation". During
your "conversation" you work through the goals, and figure you will make "dumb
UI 1.0". You estimate it, you do it. Next iteration you
evaluate things again, and maybe from the same ucd task you figure you will make
"dumb UI 1.0.0.1". I think the only important thing is that you can come up
with the most important things to do for each
iteration.

I think the concept of "story" is :-

A guide to make sure you are creating a slice of a
system that works rather than a layer within a system that provides no direct
value

Its achievable
within an iteration

can be used to make value choices - and value can include -
estimated time, cost, risk, etc

If you were an XP teams customer and you were
doing UCD "secretly". Could you work out the most important thing to do
every iteration? Could you provide guidance to the developers during that
iteration? (not that Im suggesting you would want to work this
way). If so I don't think it really matters if you have a 1 to 1
mapping or not.

This isn't a question so much as an observation. A
fact has been slowly sinking into my head, so I thought I'd throw it out
here for comment. [this is proof I actually need a
blogger.]

I've done UCD stuff for a while. I've followed a quick
sequential process of identifying organizational goals, then user
contituencies, user goals, and finally tasks user might do to meet their
goals. I then made the assertion that I could simple feed the tasks
into an XP style planning game as stories - then let XP or some other
agile process run its course with heave involvement from UCD people on the
customer side.

But, I'm finding some dissonence between the concept
of story and the user task.

A story has the quality if being
estimable - developers can estimate how long it will take to build
it. It's testable: we can write acceptance tests for it - both
automated and manual - often both are required.

A task is
thing a user does to meet one of their goals. Given that
understanding we can describe some human-computer interaction and
design some user interface.

Here's where things go
wrong.

When designing the task, I can easily break it up into a bare
bones interaction design and user interface. A design that might
make it a bit hard on the user, but is sufficient to validate an overall
approach. I often learn a bit from this initial design, and might
change the human-computer interaction significantly in response. The
quality of the task interactions might be improved in successive
iterations. The task could always be improved - I just stop when
it's good enough. And, even if it feels good enough now, as more
functionality is added to the system, I might find a task no longer
works well in the context of the rest of its tasks. Basically tasks,
which encapsulates a user and his/her goals, are never really
finished. I'm always continuously validating that user goals are
met - and adjusting if things changed.

To satisfy an agile
approach, a story must be completeable. User tasks, as I use them,
don't satisfy that.

In the past I managed this dissonance by breaking
down user stores/user tasks into bits of development work. I let
myself be comfortable with the fact that a story was never really
completed - although development tasks were. But as I move into
other agile development environments that don't have a discipline of UCD,
I'm finding that idea doesn't play so well. There's more concern in
those environments that stories have an end.

User tasks could work
if I did the design all the way. If I described the task in
sufficent detail that change was unlikely. If I described the tasks
around that task such that its context wouldn't change it. But that
the big design that agile people cringe at. And, I'm not good enough
at design to be too sure of my design work without seeing and touching it
in code. So, that level of big design doesn't work for me.

In
short strokes, I'm just getting that user tasks don't map one-to-one with
user stories. I'm not sure exactly what to do about
that.

thinking out loud.

-Jeff

Your message has been successfully submitted and would be delivered to recipients shortly.