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

Re: big projects

Expand Messages
  • Jeff Patton
    ... rejected use ... No, I m not sure I ve rejected use cases... maybe a bit more background on the problem would help. Alistair - you and I have gone over
    Message 1 of 3 , Apr 9, 2006
      --- In agile-usability@yahoogroups.com, acockburn@... wrote:
      > Hmmm, I almost hate to beat on the same old drum, but have you
      rejected use
      > cases as a mechanism for some reason?

      No, I'm not sure I've rejected use cases... maybe a bit more
      background on the problem would help.

      Alistair - you and I have gone over this before, but I see the user
      tasks I work with as sub-function - fish level use cases. I often
      assemble them into a task workflow model that for me ends up feeling
      like a use case writing excerise arranging task cards left to right
      rather than numbered steps top to bottom. In my head it still feels
      a bit like a use case, and I may stil express them vertically with
      numbered steps later, and consider extenstions for each step.

      In the agile projects I'm ending up in lately, user stories have been
      written already, and they're a bit vague. Some describe the work
      people do and could be expressed in use cases, some describe the tool
      people use to do their work - like "data table with quick column
      filtering." I can write a sub-functionish use-case that describes
      the a user quick-filtering a data table... but what's missing here is
      the motivation - the context. How quick is quick? Why would I as a
      user need to filter? Is there a better way than filtering a bit
      table to reach my goal?

      Given an already existing backlog with hundreds of these stories in
      it [painfully agreed to and prioritzed by stakeholders], a team
      asking for some idea of the user interface, and little time to back
      up and model this stuff as tasks or use cases, my response has been
      to say: "tell me a story about how someone would typically use this
      system - one that shows me how lots of these user stories connect
      together." The result has been a user scenario - at least what I'm
      calling a scenario - and looking at Writing Effective Use Cases what
      I think you'd call a usage narrative - except I number the number the
      steps so they're easier to find parts in during a discussion.

      The goal with this activity is to illustrate a typical usage path,
      with color commentary enough for me to sense why people are doing
      what they're doing. I'd like to see the scenario run through as many
      of these user stories as is reasonable so I can see why these stories
      have been prioritized high. This often means the the scenario
      wanders a little in goal level to pull in some details, and
      isn't "happy path" - shows the user encountering some difficulties
      and overcoming them.

      Given a couple of these scenarios crossing through the system, I can
      then build some simple storyboards to start to see how the
      application might look. I can begin to idenity interaction contexts
      and navigation.

      And importantly for us on the projects I'm on right now, I can help
      validate the backlog has what it needs in it: if no one can tell me a
      story - a scenario - where a user needs the thing in the backlog -
      let's get it out. If no one can tell a story without including
      things that aren't yet in the backlog, let's get those in.

      Yes, I suspect using use cases would have helped, but I sense it
      would take more time to get what I need with them. And I think task
      modeling would help - but again it might take more time than we
      have. With an hour to write a scenario, and a couple hours to
      prototype, everyone can start to visualize the system in a half day.

      The longer I do this stuff, the more tools/techniques I use -
      including use cases. But, often it depends on the team I'm working
      with, what I could most easily teach/facillitate them into getting
      results from. Today it's user scenarios - this time next year it may
      be something else. Depends on my mood and the context. The main
      goal for me is that I understand the human activities - the usage -
      before suggesting user interface. The form tht understanding is
      documented in is less important.

      Thanks,

      -Jeff
    • aacockburn
      ... been ... Ah, that s VERY different from the way I interpreted the previous ... and so ... scenarios ... The question I read this time is more: How do I
      Message 2 of 3 , Apr 10, 2006
        --- In agile-usability@yahoogroups.com, "Jeff Patton" <jpatton@...>
        wrote:
        >
        > In the agile projects I'm ending up in lately, user stories have
        been
        > written already, and they're a bit vague.
        > ... but what's missing here is
        > the motivation - the context.
        > Given an already existing backlog with hundreds of these stories

        Ah, that's VERY different from the way I interpreted the previous
        note:

        > In a message dated 4/7/2006 3:57:34 P.M. Mountain Daylight Time,
        > agile-usability@yahoogroups.com writes:
        >
        > I've been working on projects that are so huge, with so many users
        and so
        > many stories, this big models don't serve me so well. So, user
        scenarios
        > are my "killer technique" for 2006.

        The question I read this time is more: How do I make sense of
        zillions of fish-level story card?

        > The goal with this activity is to illustrate a typical usage path,
        > with color commentary enough for me to sense why people are doing

        I'll come back to your "color commentary" - to me that's important.

        > what they're doing. I'd like to see the scenario run through as
        many
        > of these user stories as is reasonable so I can see why these
        stories
        > have been prioritized high. This often means the the scenario
        > wanders a little in goal level to pull in some details, and
        > isn't "happy path" - shows the user encountering some difficulties
        > and overcoming them.
        ...
        > Yes, I suspect using use cases would have helped, but I sense it
        > would take more time to get what I need with them.

        Indeed, it seems that was never part of the options available. I like
        your 'wandering scenario' approach. It's at least as good as anything
        else for providing context after the fact.

        Back to "color commentary". This is something that I have been
        missing for a long time. And as mentioned in the previous note to
        Fredrick, it is very sensitive to the medium used to contain it.

        I am hungry for it, and generally at a loss as to how to provide
        easy, natural, low-energy ways to capture, view and change it.
        All ideas welcome.

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