Valuing stories

[hughrbeyer]

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?

Thoughts?

-------------
Hugh R. Beyer
InContext
Email: beyer@...
 

[Ron Jeffries-3]

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
www.XProgramming.com
www.xprogramming.com/blog
Assume that anything you didn't like was the funny stuff.
  -- Jim Shore

[jonathan berger]

> 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
> www.XProgramming.com
> www.xprogramming.com/blog
> Assume that anything you didn't like was the funny stuff.
> -- Jim Shore
>
>

--
_________________________
@jonathanpberger
http://www.marketpublique.com
http://www.jonathanpberger.com
718.930.2165
This email is:     [*] bloggable     [ ] ask first       [ ] private

[Scott Preece-2]

Does TDD teach that refactoring is just the last step in developing a piece of code?

scott

>
>From: Ron Jeffries <ronjeffries@...>
>To: agile-usability@...
>Sent: Saturday, September 5, 2009 12:35:22 PM
>Subject: Re: [agile-usability] Valuing stories
>
>  
>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
>>www.XProgramming. com
>>www.xprogramming. com/blog
>>Assume that anything you didn't like was the funny stuff.
>>  -- Jim Shore
>
>
> > >  

[Ron Jeffries-3]

Hello, Scott.  On Saturday, September 5, 2009, at 5:55:42 PM, you
wrote:

> Does TDD teach that refactoring is just the last step in developing a piece of code?

TDD includes a refactoring step, but it's not the only time one
would refactor.

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
It is a bad plan that admits of no modifications. -- Publius Syrus (ca. 42 BCE)

[George Dinwiddie]

jonathan berger wrote:
>> 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?

Not everything you do has to be a story.

Design?  Design is something you should do all the time.  Every time you
touch the code, you should think about design.  When you discuss new
stories, you should think about design.  When you write code, it should
reflect the design in your thoughts.

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.

  - George

--
  ----------------------------------------------------------------------
   * George Dinwiddie *                      http://blog.gdinwiddie.com
   Software Development                    http://www.idiacomputing.com
   Consultant and Coach                    http://www.agilemaryland.org
  ----------------------------------------------------------------------

[William Pietri]

Hi, Hugh. Interesting question.

hughrbeyer wrote:
> So, fer instance--the value of a user story. Some ways to think about it:
>
> 1. A story should deliver working, useful code. [...]
> 2. A story should deliver real customer value.[...]
> 3. [...] A story should reduce the risk of the project. [...]
>
> 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 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. Occasionally it's
necessary to use some proximate measure for that, like when you have
iterations that deliver internally before release. But generally, we
should only count work that delivers value to our audience.


Regarding your three categories, I'd say the code is irrelevant; it's
the "working, useful" bit that matters. In which case, it sounds like
the same thing as #2. And you can unify the other two by treating them
as risk-adjusted value.

For example, if your project is worth $1m and has a 50% chance of
failure, the risk-adjusted value is $500k. A story that cuts the risk in
half shifts the project's risk-adjusted value from $500k to $750k,
making the story worth $250k.

So I think you're entirely on the right track, and all of those are
aspects of story value.

William

[Mike Dwyer-2]

the planning session should be a negotiation that results in a sprint plan of the most viable, valuable stories in the backlog. Teams that do not enter into a conversation with the product owner regarding what they can and cannot do in a sprint are  not IMO doing their job transparently.
Sent via BlackBerry by AT&T

-----Original Message-----
From: William Pietri <william@...>

Date: Sat, 05 Sep 2009 17:15:20
To: <agile-usability@...>
Subject: Re: [agile-usability] Valuing stories


Hi, Hugh. Interesting question.

hughrbeyer wrote:
> So, fer instance--the value of a user story. Some ways to think about it:
>
> 1. A story should deliver working, useful code. [...]
> 2. A story should deliver real customer value.[...]
> 3. [...] A story should reduce the risk of the project. [...]
>
> 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 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. Occasionally it's
necessary to use some proximate measure for that, like when you have
iterations that deliver internally before release. But generally, we
should only count work that delivers value to our audience.


Regarding your three categories, I'd say the code is irrelevant; it's
the "working, useful" bit that matters. In which case, it sounds like
the same thing as #2. And you can unify the other two by treating them
as risk-adjusted value.

For example, if your project is worth $1m and has a 50% chance of
failure, the risk-adjusted value is $500k. A story that cuts the risk in
half shifts the project's risk-adjusted value from $500k to $750k,
making the story worth $250k.

So I think you're entirely on the right track, and all of those are
aspects of story value.

William

[Ron Jeffries-3]

Hello, jonathan.  On Saturday, September 5, 2009, at 5:53:05 PM,
you wrote:

>> 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?

I believe I answered that, when I said:

>> 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.

and ...

>> 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.

With those in mind ... could you rephrase your question?

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
Accroche toi a ton reve.  --ELO

[William Pietri]

jonathan berger wrote:
> 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?

Design is a pervasive concern. As George says, teams should do design
all the time. In fact, teams are doing design all the time. The choice
isn't between designing and not designing; it's between designing well
and designing poorly.

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.

As to measuring a good user experience, the easiest way to do that is by
releasing, and then watching and talking with the users. That's
sufficient to make a lot of progress, so I always encourage teams to
start with that.

William

[Adrian Howard]

On 5 Sep 2009, at 22:53, jonathan berger wrote:

> 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?

Which particular meaning of "design" are we talking about here? The  
"design" of the code (class hierarchies, etc.)? Or "design" in the big-
D / product design / industrial design sense (ideation, etc.)

If the former - then I'm with George/William. It's something you do  
all of the time.

If the latter - then I think there's probably some interesting corners  
to explore.

Adrian
--
http://quietstars.com  -  twitter.com/adrianh  -  delicious.com/adrianh

[Adrian Howard]

On 6 Sep 2009, at 01:06, George Dinwiddie wrote:

> 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.

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.

When I start looking at the underlying reason we're having UX-only  
stories I often find that we've not been paying enough attention to  
the UX when it comes to the definition of done-done.

Cheers,

Adrian
--
http://quietstars.com  -  twitter.com/adrianh  -  delicious.com/adrianh

[Adam Sroka-3]

On Sun, Sep 6, 2009 at 12:35 AM, Adrian Howard<adrianh@...> wrote:

>
>
> On 6 Sep 2009, at 01:06, George Dinwiddie wrote:
>
>> 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.
>
> 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.
>
> When I start looking at the underlying reason we're having UX-only
> stories I often find that we've not been paying enough attention to
> the UX when it comes to the definition of done-done.
>

I think the UX element has two sides just like everything else. There
is the customer feedback/market research aspect, which is primarily a
business concern. Then, there are the technical concerns: What happens
if I click this button? Does that make sense? consistency,
look-and-feel, etc. Those are responsibilities of the technical team,
with vision and direction provided by business. Regardless of which of
the two we are talking about they are both elements of each and every
story and not stories into themselves.

[Biju vv]

My team is in the process of writing user stories. UxD team member is part of the team and is going to interact with PO to come with Wireframes. The application is desktop based interactive application.
Can anyone point the best practices followed in coming with wireframes with minimal re-work during the sprint.
Other point which I want to bring up is after the User story is written and wireframes done then only we are planning to do the story point sizing. Any other suggestion would be helpful to refine the approach.
My role is Scrummaster in the team.

To: agile-usability@...
From: adam.sroka@...
Date: Sun, 6 Sep 2009 00:41:09 -0700
Subject: Re: [agile-usability] Valuing stories















 




   
                  On Sun, Sep 6, 2009 at 12:35 AM, Adrian Howard<adrianh@...> wrote:

>

>

> On 6 Sep 2009, at 01:06, George Dinwiddie wrote:

>

>> 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.

>

> 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.

>

> When I start looking at the underlying reason we're having UX-only

> stories I often find that we've not been paying enough attention to

> the UX when it comes to the definition of done-done.

>



I think the UX element has two sides just like everything else. There

is the customer feedback/market research aspect, which is primarily a

business concern. Then, there are the technical concerns: What happens

if I click this button? Does that make sense? consistency,

look-and-feel, etc. Those are responsibilities of the technical team,

with vision and direction provided by business. Regardless of which of

the two we are talking about they are both elements of each and every

story and not stories into themselves.



 

     

   
   
       
       
       
       


       


       
       
_________________________________________________________________
Log on to MSN India for a lowdown on what’s hot in the world today
http://in.msn.com

[Mike Dwyer-2]

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: agile-usability@...
[mailto:agile-usability@...] On Behalf Of jonathan berger
Sent: Saturday, September 05, 2009 5:53 PM
To: agile-usability@...
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@...
<mailto:ronjeffries%40acm.org> > 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
> www.XProgramming.com
> www.xprogramming.com/blog
> Assume that anything you didn't like was the funny stuff.
> -- Jim Shore
>
>

--
_________________________
@jonathanpberger
http://www.marketpublique.com
http://www.jonathanpberger.com
718.930.2165
This email is: [*] bloggable [ ] ask first [ ] private




 
 

[jonathan berger]

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
it.

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: agile-usability@...
> [mailto:agile-usability@...] On Behalf Of jonathan berger
> Sent: Saturday, September 05, 2009 5:53 PM
>
> To: agile-usability@...
> 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
>> www.XProgramming.com
>> www.xprogramming.com/blog
>> Assume that anything you didn't like was the funny stuff.
>> -- Jim Shore
>>
>>
>
> --
> _________________________
> @jonathanpberger
> http://www.marketpublique.com
> http://www.jonathanpberger.com
> 718.930.2165
> This email is: [*] bloggable [ ] ask first [ ] private
>
>

--
_________________________
@jonathanpberger
http://www.marketpublique.com
http://www.jonathanpberger.com
718.930.2165
This email is:     [*] bloggable     [ ] ask first       [ ] private

[George Dinwiddie]

Adrian Howard wrote:

> On 6 Sep 2009, at 01:06, George Dinwiddie wrote:
>
>> 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.
>
> 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.

I'd like to hear some stories about that.  I suspect I'm not envisioning
the same situations that you are.

> When I start looking at the underlying reason we're having UX-only  
> stories I often find that we've not been paying enough attention to  
> the UX when it comes to the definition of done-done.

On the other hand, I've seen stories grow huge because of the need to
match Photoshopped wireframes.  And then seen them cycle between dev &
test as the organization of the wireframe didn't quite match the
organization of the underlying data in all cases.  And developers
spending large amounts of time trying to duplicate whizz-bang in-browser
javascript features as specified by the UX designer.  In other words,
I've seen this result in a most un-agile situation because the UX was
treated as a requirement rather than something designed in conjunction
with the software.

I've often thought it was appropriate to split a story to include a
basic UI that was functional without javascript, and embellishments that
added to the user experience in Web 2.0 ways.

  - George

--
  ----------------------------------------------------------------------
   * George Dinwiddie *                      http://blog.gdinwiddie.com
   Software Development                    http://www.idiacomputing.com
   Consultant and Coach                    http://www.agilemaryland.org
  ----------------------------------------------------------------------

[Adrian Howard]

On 6 Sep 2009, at 17:15, jonathan berger wrote:

> 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
> it.

Ah - the old classic of "design" meaning completely different things  
to different folk (I really must hone that ranty "ban the word  
'design'" lightning talk I've had on the back burner :-)

> 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.

What kind of things are appearing on your design tracking stories?  
Stuff related to the stories being developed? Stuff related to  
ideation? Something else?

> 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.


One of the pattern that several folk have adopted is the N-1/N+1  
pattern. When the developers are coding stories for iteration N, you  
help test and give feedback on the results of iteration N-1, while  
helping groom and refine the stories that go into iteration N+1.

It's one of the practices that Jeff Patton talks about in his "Twelve  
emerging best practices for adding UX work to Agile development"  
article which I think you might find useful

http://www.agileproductdesign.com/blog/emerging_best_agile_ux_practice.html

Lots of great stuff there. I am particular ranty fan of "12. Become a  
design facilitator" - which I personally think is the key to working  
effectively in agile environments.

To be honest though - I'm not 100% convinced with the N+1/N-1 pattern.  
It hasn't felt quite right to me when I've tried it for a two reasons:

1) I find it makes me feel disconnected from the work the dev team is  
doing. I think it makes it hard for me to give the appropriate level  
of attention to what's happening "now". I've also encountered some  
folk who have, I think, misinterpreted it to mean that the UX team  
works separately from the rest of the dev folk - which is a big anti-
pattern for me.

2) The other reason is that I'm beginning to think that some of the  
rhythms and cadences of the UX work don't map well onto iteration  
lengths. Some seem shorter (as the rhythms of TDD or Continuous  
Integration are on the dev side). Some seem longer (as the rhythm of  
releases sometimes is, or if you're an XP2E person - things like  
Quarterly Cycles.)

The bad news is I unfortunately don't yet have any solid ideas for how  
to fix this :-) I've been pondering some of the things I've been  
seeing kanban folk talk about where they have an explicit  
representation of features being refined until they're small enough to  
go into dev in a confident way... but I've not done it in "real life"  
- or thought it through enough to feel like attempting to do so - so I  
could be talking complete tosh!

You might also like digging into some of the experience reports from  
the UX stage at Agile 2009. I think you might find:

* http://www.agile2009.org/node/2765
* http://www.agile2009.org/node/2853
* http://www.agile2009.org/node/3078

of interest. Hopefully some of those folk will be sticking slides /  
more info up online somewhere at some point.

Hope this is of some use!

Cheers,

Adrian

--
http://quietstars.com  -  twitter.com/adrianh  -  delicious.com/adrianh

[Hassan Schroeder-2]

On Sat, Sep 5, 2009 at 8:31 PM, William Pietri<william@...> wrote:

> .... In fact, teams are doing design all the time. The choice
> isn't between designing and not designing; it's between designing well
> and designing poorly.

Or between designing consciously and designing unconsciously,
the latter being fairly close to "not designing"  :-)

--
Hassan Schroeder ------------------------ hassan.schroeder@...
twitter: @hassan

[Adam Sroka-3]

On Sun, Sep 6, 2009 at 3:52 AM, Biju vv<biju_v_v@...> wrote:
>
> Can anyone point the best practices followed in coming with wireframes with
> minimal re-work during the sprint.


The best practice is probably not to do wireframes. Or, at least, to
spend very little time on very basic wireframes and let the design
evolve over time.

The problem with wireframes is analogous to the problem with UML
designs. They aren't working software, and there is a tendency to
over-design with them. e.g. The navigation goes here (What
navigation?) The help button goes here (What help button?) Etc.

The desire to create a complete design before you have working
software is similar to the desire of many programmers to design an
entire SOA/J2EE stack before creating a web page. As an Agile
programmer I know that I can just throw up a page, and if I need
SOA/J2EE I will be able to find it later.

To be successful in an Agile environment designers need to embrace the
same values that programmers do. It is only necessary or desirable to
develop the parts of the design that are specific to the story at
hand. So, in early stories designers will be thinking about what
colors to use, when should an alert pop up? What kind of control
should we use that will make sense to the user? Etc. Later, when the
system begins to evolve, they will be able to worry about how the new
pieces fit into the whole system.

As far as "rework," certainly as the product evolves old elements of
the design will be supplanted by new ones which means that things that
were written earlier may have to change. If you believe that this is
avoidable and/or that avoiding it is desirable, then I suggest you go
back to RUP, waterfall, or whence ye came. If, on the other hand, you
recognize that there is value in being able to change your mind to
meet the customer/market then you should call it what it is - it's not
"rework," it's refinement.