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

big projects

Expand Messages
  • acockburn@aol.com
    In a message dated 4/7/2006 3:57:34 P.M. Mountain Daylight Time, agile-usability@yahoogroups.com writes: Incidentally, last year big task models built for user
    Message 1 of 3 , Apr 7, 2006
    • 0 Attachment
      In a message dated 4/7/2006 3:57:34 P.M. Mountain Daylight Time, agile-usability@yahoogroups.com writes:


      Incidentally, last year big task models built for user stories was my
      "killer technique" for pulling some coherence into agile projects, this year
      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.  I'd like to get a little more studied
      on them - or at least clean up my references when I cite them.

      --->
      Hmmm, I almost hate to beat on the same old drum, but have you rejected use cases as a mechanism for some reason? We had 240 of them on one 70 work-year project, and I have heard of projects with more. Assuming 10 or 20 user stories per use case, you would be able to handle a project with several thousand user stories this way. And with the altitude-based goal-level linking, there's always a "top" story to start reading and traversing from.
       
      Maybe you could do the next use case experiment - Replace the dry use case text with a concrete scenario, but keep the extension conditions intact. Then you could have a readable story and also the branching.  Been wanting to try this experiment for some time. This could be the chance!
       

      ==========================================

      Alistair Cockburn
      Humans and Technology

      801.582.3162     1814 Ft Douglas Cir,  Salt Lake City, UT 84103
      http://alistair.cockburn.us/   | acockburn@...
       
      ==============================================

      "La perfection est atteinte non quand il ne reste rien a ajouter,
      mais quand il ne reste rien a enlever." (Saint-Exupery)

      "The first thing to build is trust." -- Brad Appleton

      ==============================================

    • 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 2 of 3 , Apr 9, 2006
      • 0 Attachment
        --- 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 3 of 3 , Apr 10, 2006
        • 0 Attachment
          --- 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.