RE: [agile-usability] Valuing stories
- Golly. Take a labor day holiday and see what happens. Some thoughts in response to your very insightful thinking:
Ron: Some forms of user research, it seems to me, are like market
research. They are part of the customer's job.
Yes. A lot of work is required to do the customer's job well, and it's better dealt with outside the iterations of software. What's confusing is we use the same set of terms ("UX" for example) to talk about this and also about the detailed UI design, which *does* belong in the iterations.
Ron again: 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.
This runs up against another rule I like, which is: If you don't have a story for it, and no test is broken, don't do it. Which means you only refactor when you're touching the code anyway, and then you can estimate the story to include refactoring. This guards against the tendency I've seen to make the code ever-prettier without actually advancing user value.
Adrian: Personally I find user stories that just focus on UX improvements a
little bit of a personal red flag. Like refactoring cards they're a
sign that we've gone down a bad route for long enough that we can't
fix something in-story.
Another useful concept people were throwing around at the conference is the idea of technical debt. So if your architecture is suffering entropy, you're accumulating techical debt which will have to be repaid one day.
What I think Adrian is getting to iis the idea of (UX) design debt--the coherence of the system as experienced by the user, and the fit of the system to the users' work, also has to be maintained through the iterations. And just as SW types have to pull their heads out of the individual stories to look across the system and identify architectural issues, UX designers have to step out of the iterations and look across the user experience to keep it coherent. If they don't, the system accumulates design debt that will have to be paid sometime.
Ron: 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.
One of the themes of this conferences was growing Agile methods up to meet the needs of eterprise-level projects, and part of that certainly would be to consider all the elements of customer value in a shipped system, which go well beyond jus the software. Some folks from Borland had a good paper on problems fitting the Agile process to non-agile groups also involved in product delivery.
Jonathan: 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?
William: If the user experience matters for your product, then I advise teams to
default to getting that right in every story. Ditto for every other sort
of design, too.
I like William's approach. "Done" has to include "acceptable to users"--Agile projects run into problem when the team disinvests from the UX/UE. Yes, there are people who have special expertise there, but if the SW folks on the team think that the UX being right is somebody else's problem, they're breaking a fundamental rule of being agile.
Part of the problem is timeframe--it simply takes too long to do all the UX work with the UX people teams typically have inside a single iteration. That's why, as Adrian mentions, the N-1/N+1 scheme works, where the UX people start on a story an iteration ahead.
George: Improving the user experience can be a story. But for it to be a story,
it has to drive all the way through to functional software. Doing paper
prototypes is just a task. It don't mean a thing until it gets realized
in the code.
Say it doesn't mean a thing until it's realized in the *product* and I'm with you. We have to remember the product isn't just the code. Now: should the team running their sprints worry about anything but code?
William: I encourage people not to account for all those other tasks...
My default position is that teams should only count things when they
deliver value to the people we're trying to serve.
I'm allergic to doing work with no way to account for it. It screws up your velocity in the first place, and work you're not tracking is work you don't care about in the second. I'd rather keep the story as the unit of user value and track tasks to implement the story which may well include non-software tasks.
Hugh R. Beyer, CTO
Ph: 603 966-7188
From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of hughrbeyer
Sent: Saturday, September 05, 2009 11:32 AM
Subject: [agile-usability] Valuing stories
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?
Hugh R. Beyer
- 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