Loading ...
Sorry, an error occurred while loading the content.

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

Expand Messages
  • Keith Nicholas
    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
      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". 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.
      That's my random thoughts anyways....

      From: Jeff Patton [mailto:jpatton@...]
      Sent: Tuesday, 9 November 2004 11:24 a.m.
      To: agile-usability@yahoogroups.com
      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
      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

      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.


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