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

Valuing stories

Expand Messages
  • hughrbeyer
    Hi guys -- I ve been following this group irregularly, but haven t participated much--I ll try to be better about that. I came away from Agile 09 with lots of
    Message 1 of 53 , Sep 5, 2009
    • 0 Attachment
      Hi guys -- I've been following this group irregularly, but haven't participated much--I'll try to be better about that. I came away from Agile 09 with lots of ideas and insights I'd like to get a cross-check on.

      So, fer instance--the value of a user story. Some ways to think about it:

      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? 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?

      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.

      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.

      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?

      Thoughts?

      -------------
      Hugh R. Beyer
      InContext
      Email: beyer@...
    • 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.