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

Re: [agile-usability] Valuing stories

Expand Messages
  • jonathan berger
    Lots of great feedback! To clarify, my question has more to do with the integration of a dedicated (UX) designer on an agile team. I _am_ that designer, I have
    Message 1 of 53 , Sep 6, 2009
      Lots of great feedback! To clarify, my question has more to do with
      the integration of a dedicated (UX) designer on an agile team. I _am_
      that designer, I have a great team of devs, and I came to agile
      because I saw how effective a methodology it can be. But I feel like
      Moses on the mountain: I can see the promised land, but I can't enter
      it.

      Should we write design stories separately? If so, do they have points?
      How would we measure velocity if a "design-point" is different from a
      "dev-point"? Maybe there should be a separate tracking system? We've
      found the friction caused by integrating two tracking systems results
      in the smaller system (design-tracking) breaking down because it
      ceases to reflect reality.

      So that's what I'm struggling with. I'd love to hear suggestions or
      stories relating to concrete, real-world examples or techniques for
      integrating design into agile planning.

      On Sun, Sep 6, 2009 at 8:49 AM, Mike Dwyer<mdwyer@...> wrote:
      >
      >
      > Keep in mind that viability is not limited to quantitative quality control
      > measures.  Design and usability (to a great extent) defies precision and
      > fits best in the world of probability and heuristics, as it reflects one
      > person attempting to predict the preferences of groups of people who have
      > not experienced what is being designed. IMO that is why UX and UI is at the
      > cutting edge of emergent theory and practice.  Lessons can be learned from
      > others who work in the field and one of the most basic sets is found in the
      > Agile Principles.  Do as little as needed to deliver exactly what is asked
      > for.  When coupled with high customer contact, iterative and incremental
      > development, practitioners get to take full advantage of the failures and
      > move quickly to stumble across an acceptable solution.  This readies them to
      > do a better job at it the next time.  Sounds frustrating, but it is the what
      > many experience from living on the edge.
      >
      >
      >
      > Mike Dwyer
      > "Planning constantly peers into the future for indications as to where a
      > solution may emerge."
      >
      > "A Plan is a complex situation, adapting to an emerging solution."
      >
      >
      >
      > From: agile-usability@yahoogroups.com
      > [mailto:agile-usability@yahoogroups.com] On Behalf Of jonathan berger
      > Sent: Saturday, September 05, 2009 5:53 PM
      >
      > To: agile-usability@yahoogroups.com
      > Subject: Re: [agile-usability] Valuing stories
      >
      >
      >
      >
      >
      >> I see too many teams who lose the benefits of the agile process by
      >> accepting almost any damn thing as a story.
      >
      > Ok, great, sure, you've got a very orthodox view of agile, and that's
      > cool. I buy that. But the question I struggle with is this: where does
      > design fit in? Do you write separate design stories? Is design part of
      > a development story? Is a story acceptable if the functionality is
      > there but its a poor UE? How do you measure "good" UE if UE can't be a
      > story because its not software?
      >
      > On Sat, Sep 5, 2009 at 1:35 PM, Ron Jeffries<ronjeffries@...> wrote:
      >>
      >>
      >> Hello, hughrbeyer. On Saturday, September 5, 2009, at 11:32:13
      >>
      >> AM, you wrote:
      >>
      >>> 1. A story should deliver working, useful code. This is the
      >>> traditional XP approach. It's fine, but limiting. Refactoring
      >>> delivers working code, but that code was already working--why does
      >>> it count?
      >>
      >> Generally speaking, refactoring doesn't count as a user story. I
      >> teach teams to keep refactoring in the background because it is so
      >> difficult to compare it to things that seem like revenue.
      >>
      >>> User research or testing delivers a better understanding
      >>> of users, which is valuable, and will change the code eventually,
      >>> but not right away. Why shouldn't it count?
      >>
      >> Some forms of user research, it seems to me, are like market
      >> research. They are part of the customer's job. The customer can do
      >> those any way she wants. They are not part of the software
      >> development team's activities at all ... because they don't result
      >> in software (just then).
      >>
      >> Some user research is done by creating software for users to use and
      >> researchers to observe. That's software development: it can be a
      >> story. Its business value is information. As such the customer can
      >> schedule it the same way she would any other story.
      >>
      >>> 2. A story should deliver real customer value. This gives us a
      >>> little more flexibility. Well-structured code is more valuable
      >>> than poorly structured code. And, I'd claim, understanding users
      >>> and their needs is also valuable, though again only because it
      >>> changes what the design team will then do.
      >>
      >> Yes. Again, I don't count refactoring as a story. I would count
      >> development of a piece of software to do user experience with as a
      >> story. I would not treat a paper prototype or other non-software UX
      >> tool as a story.
      >>
      >>> 3. In his keynote, Alistair suggested another way to think about
      >>> it: A story should reduce the risk of the project. This is nice
      >>> because thinking about risk gives us more flexibility. Not having
      >>> working code is clearly a risk--but poorly structured code is also
      >>> a risk. And, I'd add, not understanding your user, or having
      >>> untested designs are a risk.
      >>
      >> Sure. There is business value in reduction of risk. This should not
      >> be news to us.
      >>
      >>> In the end though, I still feel that a "user story" pretty much
      >>> has to define some part of the user experience. If that experience
      >>> is delivered through code, fine--if not, also fine. It's still a
      >>> story. But then how do we account for all these other tasks?
      >>
      >> I believe it is very important for the software development team to
      >> produce software. I see too many teams who lose the benefits of the
      >> agile process by accepting almost any damn thing as a story.
      >>
      >> We could imagine, however, running a larger team, with a software
      >> team inside it, using the planning and execution style of an agile
      >> process, but this time not focused on software but some other
      >> carefully chosen set of deliverables. I think of that as a sort of
      >> containing team. Clearly with a customer and team with their eye
      >> totally on the ball, one could relax away from my concern about a
      >> strict focus on software.
      >>
      >> Ron Jeffries
      >> www.XProgramming.com
      >> www.xprogramming.com/blog
      >> Assume that anything you didn't like was the funny stuff.
      >> -- Jim Shore
      >>
      >>
      >
      > --
      > _________________________
      > @jonathanpberger
      > http://www.marketpublique.com
      > http://www.jonathanpberger.com
      > 718.930.2165
      > This email is: [*] bloggable [ ] ask first [ ] private
      >
      >



      --
      _________________________
      @jonathanpberger
      http://www.marketpublique.com
      http://www.jonathanpberger.com
      718.930.2165
      This email is: [*] bloggable [ ] ask first [ ] private
    • Adrian Howard
      ... I think that they re probably an orthogonal dimensions myself. I ve met people who make very good decisions about the design of the code/ ux - but are not
      Message 53 of 53 , Sep 11, 2009
        On 6 Sep 2009, at 21:27, Hassan Schroeder wrote:

        > On Sat, Sep 5, 2009 at 8:31 PM, William Pietri<william@...>
        > wrote:
        >
        >> .... In fact, teams are doing design all the time. The choice
        >> isn't between designing and not designing; it's between designing
        >> well
        >> and designing poorly.
        >
        > Or between designing consciously and designing unconsciously,
        > the latter being fairly close to "not designing" :-)


        I think that they're probably an orthogonal dimensions myself. I've
        met people who make very good decisions about the design of the code/
        ux - but are not really able to articulate the reasoning behind them
        very well.

        This can be problematical since their decisions can sound arbitrary to
        others - even when they're really good decisions.

        Cheers,

        Adrian

        --
        http://quietstars.com - twitter.com/adrianh - delicious.com/adrianh
      Your message has been successfully submitted and would be delivered to recipients shortly.