Re: [agile-usability] Valuing stories
- Hello, jonathan. On Saturday, September 5, 2009, at 5:53:05 PM,
>> I see too many teams who lose the benefits of the agile process by accepting almost any damn thing as a story.I believe I answered that, when I said:
> 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?
>> Some forms of user research, it seems to me, are like marketand ...
>> 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.
>> I believe it is very important for the software development team toWith those in mind ... could you rephrase your question?
>> 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.
Accroche toi a ton reve. --ELO
- On 6 Sep 2009, at 21:27, Hassan Schroeder wrote:
> On Sat, Sep 5, 2009 at 8:31 PM, William Pietri<william@...>I think that they're probably an orthogonal dimensions myself. I've
>> .... In fact, teams are doing design all the time. The choice
>> isn't between designing and not designing; it's between designing
>> and designing poorly.
> Or between designing consciously and designing unconsciously,
> the latter being fairly close to "not designing" :-)
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
This can be problematical since their decisions can sound arbitrary to
others - even when they're really good decisions.
http://quietstars.com - twitter.com/adrianh - delicious.com/adrianh