RE: [agile-usability] Valuing stories
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.
"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."
accepting almost any damn thing as a story.
> I see too many teams who lose the benefits of the agile process by
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
>> 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
> Assume that anything you didn't like was the funny stuff.
> -- Jim Shore
This email is: [*] bloggable [ ] ask first [ ] private
- 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