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

RE: [agile-usability] Business Goals

Expand Messages
  • Desilets, Alain
    Prioritization of user stories happens against a backdrop of an understanding of user goals, and business goals. It was from Larry & Lucy that I first learned
    Message 1 of 7 , Apr 5, 2006
      Message
      Prioritization of user stories happens against a backdrop of an understanding of user goals, and business goals.  It was from Larry & Lucy that I first learned the value of simple models that encapsulate my understanding.  To model business goals lately I’ve been using an approach my friend Julias pointed me to: GQM – short for goal question metric.  [Google around and you’ll find lots of references including a pricy Forrester Research report and an somewhat expensive book.]  Basically, if you have a business goal, ask “how would you know you were reaching this goal?”  Poke the goal long enough with questions and you’ll realize it’s either a dumb goal, or it’ll mutate into one that has some metrics that will help you understand how the goal is being reached.  A collection of goals with metrics makes up my business goal model.  The list is prioritized – or rather there are focal goals.  To understand users I’ll build both user role models and task models.  I’ll then ask stakeholder using the backdrop of the goal model to identify focal roles and tasks.  It’s much easier to identify the users the software needs to satisfy with the goal model visible.  I’ve found it makes the whole process go smoother. 
       
      -- Alain:
      Question for you. Do you work on defining the Business Goals BEFORE defining User Roles and User Tasks, or AFTER? In your paper "What Goes Up Must Come Down", you seem to be saying that high level kite-and-above level goals (which are more or less equivalent to Business Goals) should at least be partially distilled based on knowlege about the lower level goals (although as you point out, it is best to work in both top-down and bottom-up directions). But to me, Business Goals is the one thing that I believe CAN be articulated mostly upfront, and I tend to favour that approach (although I tend to favour a "middle-out" approach for lower level details).
      ---- 

       

      Again, it boils down to these sorts of models and the guidance they give.  Don’t skimp on parts of the software used for focal users engaged in focal tasks that by definition – because they’re focal – are critical to the business goals of the software.  But for not so focal users engaged in infrequent tasks, barely sufficient is the rule.  I’ve met many usability people that look for usability at any cost.  That’s just not practical – not with my money or my customer’s money.  Sometimes usability testing overstates the concerns of the person behind the keyboard and understates the concerns of the stakeholders who paid for the software.   

       

      -- Alain:

      The converse is of course also true. Agilist sometimes pay too much attention to the concerns of the "Gold Owner" (the person who pays for development), without realising in order to achieve that person's Business Goals, you HAVE to pay a lot of attention to the people behind the keyboard (or at least the focal ones).

       

      In my view, this gold customer-centric vs user-centric difference is the main source of misunderstanding between the Agile and Usability community, and the work that you (Jeff) are doing goes a long way towards bringing those two perspective together.

      ----

    • Jeff Patton
      ... I often come into a project late - after it s started. Lately I often come in to do a bit of rescue work on the user interactions. In those situations
      Message 2 of 7 , Apr 5, 2006
        --- In agile-usability@yahoogroups.com, "Desilets, Alain"
        <alain.desilets@...> wrote:

        > -- Alain:
        > Question for you. Do you work on defining the Business Goals BEFORE
        > defining User Roles and User Tasks, or AFTER? In your paper "What Goes
        > Up Must Come Down", you seem to be saying that high level kite-and-above
        > level goals (which are more or less equivalent to Business Goals) should
        > at least be partially distilled based on knowlege about the lower level
        > goals (although as you point out, it is best to work in both top-down
        > and bottom-up directions). But to me, Business Goals is the one thing
        > that I believe CAN be articulated mostly upfront, and I tend to favour
        > that approach (although I tend to favour a "middle-out" approach for
        > lower level details).
        > ----

        I often come into a project late - after it's started. Lately I often
        come in to do a bit of "rescue" work on the user interactions. In
        those situations there's often an absence of business goals, or a set
        of ambiguous business goals that don't seem well connected to the
        users and scope chosen. So, I'll work bottom up to reconstruct a goal
        model from what I observe people actually building. Then review my
        observations about the business goals I see being pursued based on
        what people are actually doing. When coming in late to a project I
        might prefer to spend a bit of time with stakeholders on business
        goals first, but this sort of work is often seen as regressive -
        everyone already believes they know what the goals are. "Just get to
        work on this UI stuff! That's where we need the help." Not until I
        point out deviation from goals does rewinding and discussing a more
        concise goal model become important.

        In a greefield situation I put together goals first. But I always
        move up and down validating users and activities we choose to support
        with goals we hope to achieve. Doing this uncovers both missing users
        and tasks, and missing business goals.

        I try to avoid waterfall head - by that I mean only moving down from
        high level to lower level, insisting high level models are complete
        before moving on to lower levels, and always assuming what what done
        in a higher level phase was correct. Levarage agile feedback loops to
        validate and further refine these higher level models.

        > -- Alain:
        > The converse is of course also true. Agilist sometimes pay too
        > much attention to the concerns of the "Gold Owner" (the person who pays
        > for development), without realising in order to achieve that person's
        > Business Goals, you HAVE to pay a lot of attention to the people behind
        > the keyboard (or at least the focal ones).

        Where agilists might fall down is in the creation of these mezzenine
        level models - things like goal models, user models, task models, etc.
        All this stuff starts to smell of big design up front to some agile
        people. The thing to remember is that it's not the model that
        represents waterfall thinking, it's the way be build and work with the
        model that makes in waterfallish - and potentially risk.

        I look at user stories like leaves on a tree. I'll try to build
        simple models that start to give form to the tree - a trunk, branches,
        then finally leaves. Unfortunately in a lot of agile projects all
        that exists are user stories. Sort of like pulling all the leaves off
        the tree, cutting down and chopping up the tree, then handing you the
        leaves in a leaf bag. This leaf-bag-style story backlog is a common
        agile project smell. I spend a fair bit of time forensically
        reconstructing mezzenine level model from the leaf-bag-o-details found
        in a story backlog. Everyone's often surprised at the tree they're
        actually building - the users, tasks, and business goals they really
        chose to support.

        Thanks Alain for keeping this discussion going.

        Opinions anyone? Is anyone out there working on an agile project
        where goals seem ambiguously defined? Does this cause problems
        prioritizing and detailing user stories? Actually scratch agile from
        the previous sentances. Agile development certainly doesn't have a
        corner in the ambiguous goals market.

        -Jeff
      • Jeff Patton
        Forgot to say something - see below... ... pays ... What I didn t bring out above is that the creation of these models helps the gold owner more effectively
        Message 3 of 7 , Apr 5, 2006
          Forgot to say something - see below...

          --- In agile-usability@yahoogroups.com, "Jeff Patton" <jpatton@...> wrote:
          > > The converse is of course also true. Agilist sometimes pay too
          > > much attention to the concerns of the "Gold Owner" (the person who
          pays
          > > for development)...

          > Where agilists might fall down is in the creation of these mezzenine
          > level models - things like goal models, user models, task models, etc.

          What I didn't bring out above is that the creation of these models
          helps the "gold owner" more effectively stear the project, and makes
          the direction the project is being steared in more visible to the
          whole team. Without them, the decisions the "gold owner" make often
          seem arbitrary and subjective - at times even to themselves. These
          sorts of models are quick to create, useful tools. I'll assert that
          as a development team we're not serving our "gold owners" well if we
          don't help them with things like this.

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