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

user tasks aren't stories

Expand Messages
  • Jeff Patton
    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
    Message 1 of 4 , Nov 8, 2004
    • 0 Attachment
      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
    • Chris Pehura
      In 100% agreement. There purposes are very different. Stories are used for communication between people. User tasks help direct the implementation. There is
      Message 2 of 4 , Nov 8, 2004
      • 0 Attachment
        In 100% agreement.
         
        There purposes are very different.
        Stories are used for communication between people.
        User tasks help direct the implementation.
         
        There is some common ground between them, like you said,
        even though their purposes are very different.
        -----Original Message-----
        From: Jeff Patton [mailto:jpatton@...]
        Sent: Monday, November 08, 2004 4:24 PM
        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
        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




      • William Pietri
        ... I d generally agree with that, mostly. I think of user stories as addressing user needs, not completely fulfilling them. Could it be that the gap you re
        Message 3 of 4 , Nov 8, 2004
        • 0 Attachment
          On Mon, 2004-11-08 at 14:24, Jeff Patton wrote:
          >
          > 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.

          I'd generally agree with that, mostly. I think of user stories as
          addressing user needs, not completely fulfilling them.

          Could it be that the gap you're noticing is betwen the ideal and the
          practical? It seems to me that if you start from organizational goals
          and work your way down, that's a fair bit of "ideally, we'd want X" by
          the time you work your way down to story cards.

          What might happen if you stopped the UCD process at a higher level than
          tasks? Suppose, for example, that you stopped with user goals and used
          those to generate story cards?

          In particular, I'm wondering if there's a way to change the question
          from, "How much of my design vision do I have to compromise?" (which is
          a pressure I often feel in the planning game) to "How many important
          user needs can we address with this week's points?"

          William
        • 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 4 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.
             
            That's my random thoughts anyways....
             
            Regards,
             
            Keith
             
             
             
             


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