Re: [agile-usability] Valuing stories
- Lots of great feedback! To clarify, my question has more to do with
the integration of a dedicated (UX) designer on an agile team. I _am_
that designer, I have a great team of devs, and I came to agile
because I saw how effective a methodology it can be. But I feel like
Moses on the mountain: I can see the promised land, but I can't enter
Should we write design stories separately? If so, do they have points?
How would we measure velocity if a "design-point" is different from a
"dev-point"? Maybe there should be a separate tracking system? We've
found the friction caused by integrating two tracking systems results
in the smaller system (design-tracking) breaking down because it
ceases to reflect reality.
So that's what I'm struggling with. I'd love to hear suggestions or
stories relating to concrete, real-world examples or techniques for
integrating design into agile planning.
On Sun, Sep 6, 2009 at 8:49 AM, Mike Dwyer<mdwyer@...> wrote:
> 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.
> Mike Dwyer
> "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."
> From: email@example.com
> [mailto:firstname.lastname@example.org] On Behalf Of jonathan berger
> Sent: Saturday, September 05, 2009 5:53 PM
> To: email@example.com
> Subject: Re: [agile-usability] Valuing stories
>> 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
>> Assume that anything you didn't like was the funny stuff.
>> -- Jim Shore
> This email is: [*] bloggable [ ] ask first [ ] private
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