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

Re: [agile-usability] Valuing stories

Expand Messages
  • Ron Jeffries
    Hello, jonathan. On Saturday, September 5, 2009, at 5:53:05 PM, ... and ... ... With those in mind ... could you rephrase your question? Ron Jeffries
    Message 1 of 53 , Sep 5, 2009
      Hello, jonathan. On Saturday, September 5, 2009, at 5:53:05 PM,
      you wrote:

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

      I believe I answered that, when I said:

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

      and ...

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

      With those in mind ... could you rephrase your question?

      Ron Jeffries
      www.XProgramming.com
      www.xprogramming.com/blog
      Accroche toi a ton reve. --ELO
    • 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.