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

Re: [agile-usability] Valuing stories

Expand Messages
  • jonathan berger
    ... 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?
    Message 1 of 53 , Sep 5, 2009
    • 0 Attachment
      > 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
    • 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
      • 0 Attachment
        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.