> 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