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 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 126.96.36.199". 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 valueIts achievable within an iterationcan be used to make value choices - and value can include - estimated time, cost, risk, etcIf 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.That's my random thoughts anyways....Regards,Keith
From: Jeff Patton [mailto:jpatton@...]
Sent: Tuesday, 9 November 2004 11:24 a.m.
Subject: [agile-usability] user tasks aren't stories
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
But, I'm finding some dissonence between the concept of story and the
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
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.