Top-down User Stories

[Jana Jecmen]

Hi All,

My company is developing the strategy for going Agile. Here is how we plan
to maintain the Backlog:

   - product management should specify a "theme",
   - product owner should write User Stories for it,
   - developers should estimate them and eventually split them into tasks.

This strategy is believed to give us a framework to stay on track and to
deliver what product management wants.

Did anybody apply a similar top-down approach in practice?

I like this strategy, but I have a nagging suspicion that this is not an
Agile methodology. Shouldn't the User Stories be created in a bottom-up
fashion in Agile?

I would appreciate your comments. Thanks,

Jana

[William Pietri]

Great question, Jana. I'm sure there will be a variety of opinions, but
here's my take.

This is not a bad way to start, and you can always do some of it, but if
this is the only way stories get written, you'll be missing some
opportunities.

In my view, good Agile teams have tight feedback loops, distributed
power, shared responsibility, and collaborative innovation. If followed
literally, this top-down flow you describe doesn't really have any of those.

Whatever approach you take, make sure from the start you have a way to
close the open feedback loop you've described. If you are assiduous in
that, your team can probably work the rest out over time. You can reduce
that amount of time through things like shortening iterations, releasing
more often, having a clear project charter, increasing the volume and
clarity of real-world data on product impact, and using an experienced
agile coach.


Hoping that helps,

William


Jana Jecmen wrote:

> Hi All,
>  
> My company is developing the strategy for going Agile. Here is how we
> plan to maintain the Backlog:
>
>     * product management should specify a "theme",
>     * product owner should write User Stories for it,
>     * developers should estimate them and eventually split them into
>       tasks.
>
> This strategy is believed to give us a framework to stay on track and
> to deliver what product management wants.
>  
> Did anybody apply a similar top-down approach in practice?
>  
> I like this strategy, but I have a nagging suspicion that this is not
> an Agile methodology. Shouldn't the User Stories be created in
> a bottom-up fashion in Agile?
>  
> I would appreciate your comments. Thanks,
>  
> Jana
>
>
>

[Ron Jeffries]

Hello, Jana.  On Tuesday, March 17, 2009, at 9:18:50 AM, you wrote:

> I like this strategy, but I have a nagging suspicion that this is not an
> Agile methodology. Shouldn't the User Stories be created in a bottom-up
> fashion in Agile?

I'd think not. User stories have business value. Business people
need to decide that. Perhaps I don't understand what you mean by
bottom-up, however.

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
Attend our CSM Plus Course!
http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28
Fatalism is born of the fear of failure, for we all believe that we carry
success in our own hands, and we suspect that our hands are weak. -- Conrad

[Adam Sroka-3]

On Tue, Mar 17, 2009 at 6:18 AM, Jana Jecmen <jana.jecmen@...> wrote:

> Hi All,
>
> My company is developing the strategy for going Agile. Here is how we plan
> to maintain the Backlog:
>
> product management should specify a "theme",
> product owner should write User Stories for it,
> developers should estimate them and eventually split them into tasks.
>
> This strategy is believed to give us a framework to stay on track and to
> deliver what product management wants.
>
> Did anybody apply a similar top-down approach in practice?
>
> I like this strategy, but I have a nagging suspicion that this is not an
> Agile methodology. Shouldn't the User Stories be created in a bottom-up
> fashion in Agile?
>

I take it that you mean "Top-down" in the sense that management is
saying what needs to be done and this is being passed down to the
team. This is a little confusing, because Agile organizations are very
flat, and the terms "top-down" vs. "bottom-up" are usually applied to
the technical design. I believe that you are using them in an
organizational sense and not a technical sense, but correct me if I am
wrong.

"Top-down" is certainly more correct than "bottom-up." But, ideally we
want a more interactive process where management provides the vision
and gives high level direction and the team fills in the details of
what needs to be done and how to do it with feedback going in both
directions.

As Ron already said it is important that user stories have business
value. So, it is important that business people are involved in
defining them and making sure that the implementation meets their
expectations (e.g. through Acceptance Testing.)

It is also important that technical team members have the right to say
what can be done and how long it will take without undue external
pressure. We want technical members to be honest and creative. We want
them to solve the business problems as best they know how while
maintaining the highest attainable quality.

So, rather than thinking in terms of "top-down" vs "bottom-up,"
perhaps it is more correct to think of two entities - the business
team and the technical team - working together to try and solve common
problems without getting in each others way. In order to do this they
need to be able to communicate and develop a shared understanding.

[William Pietri]

Ron Jeffries wrote:

> Hello, Jana.  On Tuesday, March 17, 2009, at 9:18:50 AM, you wrote:
>
>  
>> I like this strategy, but I have a nagging suspicion that this is not an
>> Agile methodology. Shouldn't the User Stories be created in a bottom-up
>> fashion in Agile?
>>    
>
> I'd think not. User stories have business value. Business people
> need to decide that. Perhaps I don't understand what you mean by
> bottom-up, however.

What I'm guessing she means is a way where the whole team collaborates
on deciding what to build, rather than it all flowing from on high. I
definitely have seen some agile teams working that way successfully.

One of the drawbacks of the classic XP approach, where the XP Customer
is the only source of business value decisions, is that developers often
don't feel engaged in that part of the process. For some people that's
fine, but some developers really want to participate in product
planning. That's especially true out here in the SF area, where
developers are often also users, or own substantial portions of the
company, or both.

There are a variety of ways to achieve that engagement, including
Google's 20% time and hack days, both of which give developers a chance
to build the things they think are important. But a little give and take
in the planning process is enough for some shops. A team at YouTube I
interviewed, for example, treats the major business goals (as expressed
in quarterly Objectives and Key Results plans) as primary, but devotes
some time to secondary goals chosen by the team.

William

[Roman Pichler]

Hi Jana,

I suggest asking the product manager to be the (chief) product owner. The individual currently assigned to the product owner role may work with the (chief) product owner in a product owner team. As others have pointed out, the entire Scrum team, product owner, team and ScrumMaster should discover and describe stories collaboratively, for instance in form of requirements workshops. There is nothing wrong with deriving stories form themes. The opposite is true: I have found it to be beneficial. Jeff's user story mapping technique follows a similar approach, for instance.

You may find the description of the product owner role in my upcoming book helpful: www.mikecohnsignatureseries.com/books/agile-product-management.

Good luck,
Roman

--- In agile-usability@..., Jana Jecmen <jana.jecmen@...> wrote:

>
> Hi All,
>
> My company is developing the strategy for going Agile. Here is how we plan
> to maintain the Backlog:
>
>    - product management should specify a "theme",
>    - product owner should write User Stories for it,
>    - developers should estimate them and eventually split them into tasks.
>
> This strategy is believed to give us a framework to stay on track and to
> deliver what product management wants.
>
> Did anybody apply a similar top-down approach in practice?
>
> I like this strategy, but I have a nagging suspicion that this is not an
> Agile methodology. Shouldn't the User Stories be created in a bottom-up
> fashion in Agile?
>
> I would appreciate your comments. Thanks,
>
> Jana
>

[Marjorie H Pries]

Jana,

I concur with all of the others who have responded so far. It should work
but it may not work. The key elements that are not well identified here
are the amount of collaboration and the nature of feedback loops.  What
strikes me in your description is step two, " the product owner should
write user stories".

The question is, how do the user stories get decided before the product
owner writes them down?  This is the point where user research &
experience, and technical research & experience, come together with
business stakeholders to work out priorities and possible solutions.

It all depends on your company's culture and the product owner's
personality. If it's biased toward a command-and-control culture, and the
product owner is not collaborative by nature,  then having that person
write down what they want built and how they want it built probably will
not provide a framework for agility.



Marjorie H. Pries
Lead Consultant / Utility Infielder

ThoughtWorks, Inc.
http://www.thoughtworks.com


"Don't believe everything you think."
     --seen on a bumpersticker



Jana Jecmen <jana.jecmen@...>
Sent by: agile-usability@...
03/17/2009 08:18 AM
Please respond to
agile-usability@...


To
agile-usability@...
cc

Subject
[agile-usability] Top-down User Stories









Hi All,
 
My company is developing the strategy for going Agile. Here is how we plan
to maintain the Backlog:
product management should specify a "theme",
product owner should write User Stories for it,
developers should estimate them and eventually split them into tasks.
This strategy is believed to give us a framework to stay on track and to
deliver what product management wants.
 
Did anybody apply a similar top-down approach in practice?
 
I like this strategy, but I have a nagging suspicion that this is not an
Agile methodology. Shouldn't the User Stories be created in a bottom-up
fashion in Agile?
 
I would appreciate your comments. Thanks,
 
Jana


 
 

[Jeff Patton]

First: Thanks to all the smart people getting back to Jana with  
thought provoking answers.

I'll chip in two-cents - and I'd like you to value my advice at  
exactly that.  Warning: I can't seem to answer questions with crisp  
advice - grab a cup of coffee before you start to read this.

> product management should specify a "theme",


I'll refine that to say that product management should specify a  
desired outcome.  By outcome I mean what happens after the software  
ships.  How does the company benefit?  What customers and users are  
relevant to that business benefit?  What sort of solution does the  
product manager believe will achieve that outcome?

I've recently been trying on for size the language used by a speaker  
from Frog who gave a keynote at IxDA 09 (I forget his name...).  He  
introduced the language output-outcome-impact

output: is what we build
outcome: is what happens in the world after we release our product
impact: is what happens later - often much later.

We don't want software (the output), rather we want the outcome - the  
profit, the increased customer satisfaction and retention, the  
expansion into new markets - all that stuff.  We're ideally driving  
towards some longer range impact aligned with our organization's  
vision - to become dominant in the marketplace, or (isn't it google  
that says) "do no harm."  If we released software that made a profit,  
but damaged our reputation in the industry, that would be a good short  
term outcome, but questionable long term impact.  I know a company  
that had made a choice to include more advertising on their site. It's  
had a good short term outcome (more revenue).  But, they're concerned  
that this move may damage their brand having questionable long term  
impact (their customers grumble about the ads).

Outcome and impact is where the business value lives.  If you don't  
know what your desired outcome and impact are, you don't know what  
your business value is.  Don't build software till you do - unless of  
course you're having fun at it... but then "fun" is your desired  
outcome.  ;-)

The product owner and team prioritize work relative to that.

> product owner should write User Stories for it,

That'll work so long as the product owner understands the desired  
outcome, gathers the information necessary write stories that could  
result in software to get that outcome, and engages in some form of  
evaluation of the software - ideally with users and others - that can  
help determine if we're likely to get that outcome.

In english now: work with a collaborative team of smart people.  Study  
the users.  Show prototypes and working software to users.  Watch them  
use it.  Continuously ask if we're likely to get that outcome when the  
software is released.  Release as soon as you can - because you never  
really know.  All software is a speculative until released - like a  
boat that's never been placed in the water - you'll know it floats  
when you actually launch it.  Sadly, I've  seen a lot of "concrete  
boats" being built.

> developers should estimate them and eventually split them into tasks.

They need to understand the desired outcome as well - as well as have  
a pretty good "big picture" of the desired product in their head.  
This let's them innovate - really think.  When they're allowed to  
think, they'll begin to move into this sweet spot of quickest to build  
and helps to secure desired outcomes.  They'll begin to be alert to  
stuff that wastes time - stuff that although they could build it,  
isn't in the best interest of organizations.

If you don't communicate the desired outcome and how you envision the  
product, the developers will still think - still invent - still come  
up with good ideas.  They just many not always be aligned with what  
you're trying to achieve.  If you're the product owner, and developers  
are coming up with what seem like irrelevant ideas, or pushing back  
against yours, don't argue with them - back up and make sure they  
understand the desired outcome, the users and customers, the product  
you're envisioning.  For teams I've worked with, it they still don't  
understand, I put them in a car (or in a plane) and go to the customer  
site to watch them work - to see the context.  They'll either  
understand, or be a little more cautious about being argumentative  
next time.

I don't have any particular concerns one way or the other about the  
separation of product manager and product owner.  Luke Hohman  
describes the scrum product owner role as a "product engineer" - a  
more tactical and technical role than the product manager normally  
fills.  I get nervous when the boundaries between any role are two  
stiff.  I picture my team and company as a bit of a soup.  (stay with  
me here.)  I can cut up a bunch of vegetables and toss them in a bowl  
- and the boundaries between the carrots and the potatoes are still  
pretty clear.  But, when I add water and heat - the soup begins to  
boil and the boundaries get a bit fuzzy.  The edges of the carrots get  
a bit blurry - and the soup tastes a lot better than the bowl of  
uncooked vegetables.  If your roles have stiff boundaries, you're  
doing it wrong (in my opinion.)

> I like this strategy, but I have a nagging suspicion that this is  
> not an Agile methodology. Shouldn't the User Stories be created in a  
> bottom-up fashion in Agile?

If you mean by that that the team creates them: no.  I've seen some  
serious problems with the product owner and product manager not really  
understanding their own backlog.  Consequently they can't "steer" the  
project.

The simple steps you describe will likely work fine - but the devil is  
in the subtlety of how you do it.  I imagine Tiger Woods explaining  
how to play golf:

1. place ball on tee
2. select golf club
3. hit ball into hole

It's simple see?   Anyone can do it.

Thanks for posting,

-Jeff
-----------------------------------------
Jeff Patton
jpatton@...
+1 801.910.7908
skype; jeff_patton
www.agileproductdesign.com

On Mar 17, 2009, at 9:18 AM, Jana Jecmen wrote:

>
> Hi All,
>
> My company is developing the strategy for going Agile. Here is how  
> we plan to maintain the Backlog:
> product management should specify a "theme",
> product owner should write User Stories for it,
> developers should estimate them and eventually split them into tasks.
> This strategy is believed to give us a framework to stay on track  
> and to deliver what product management wants.
>
> Did anybody apply a similar top-down approach in practice?
>
> I like this strategy, but I have a nagging suspicion that this is  
> not an Agile methodology. Shouldn't the User Stories be created in a  
> bottom-up fashion in Agile?
>
> I would appreciate your comments. Thanks,
>
> Jana
>
>

[George Dinwiddie]

Jeff Patton wrote:

> First: Thanks to all the smart people getting back to Jana with thought
> provoking answers.
>
> I'll chip in two-cents - and I'd like you to value my advice at exactly
> that.  Warning: I can't seem to answer questions with crisp advice -
> grab a cup of coffee before you start to read this.
>
>> product management should specify a "theme",
>
> I'll refine that to say that product management should specify a desired
> outcome.  By outcome I mean what happens after the software ships.  How
> does the company benefit?  What customers and users are relevant to that
> business benefit?  What sort of solution does the product manager
> believe will achieve that outcome?
>
> I've recently been trying on for size the language used by a speaker
> from Frog who gave a keynote at IxDA 09 (I forget his name...).  He
> introduced the language output-outcome-impact
>
> output: is what we build
> outcome: is what happens in the world after we release our product
> impact: is what happens later - often much later.
>
> We don't want software (the output), rather we want the outcome - the
> profit, the increased customer satisfaction and retention, the expansion
> into new markets - all that stuff.  We're ideally driving towards some
> longer range impact aligned with our organization's vision - to become
> dominant in the marketplace, or (isn't it google that says) "do no
> harm."  If we released software that made a profit, but damaged our
> reputation in the industry, that would be a good short term outcome, but
> questionable long term impact.  I know a company that had made a choice
> to include more advertising on their site. It's had a good short term
> outcome (more revenue).  But, they're concerned that this move may
> damage their brand having questionable long term impact (their customers
> grumble about the ads).
>
> Outcome and impact is where the business value lives.  If you don't know
> what your desired outcome and impact are, you don't know what your
> business value is.  Don't build software till you do - unless of course
> you're having fun at it... but then "fun" is your desired outcome.  ;-)
>
> The product owner and team prioritize work relative to that.
>
>> product owner should write User Stories for it,
>
> That'll work so long as the product owner understands the desired
> outcome, gathers the information necessary write stories that could
> result in software to get that outcome, and engages in some form of
> evaluation of the software - ideally with users and others - that can
> help determine if we're likely to get that outcome.
>
> In english now: work with a collaborative team of smart people.  Study
> the users.  Show prototypes and working software to users.  Watch them
> use it.  Continuously ask if we're likely to get that outcome when the
> software is released.  Release as soon as you can - because you never
> really know.  All software is a speculative until released - like a boat
> that's never been placed in the water - you'll know it floats when you
> actually launch it.  Sadly, I've  seen a lot of "concrete boats" being
> built.
>
>> developers should estimate them and eventually split them into tasks.
>
> They need to understand the desired outcome as well - as well as have a
> pretty good "big picture" of the desired product in their head.  This
> let's them innovate - really think.  When they're allowed to think,
> they'll begin to move into this sweet spot of quickest to build and
> helps to secure desired outcomes.  They'll begin to be alert to stuff
> that wastes time - stuff that although they could build it, isn't in the
> best interest of organizations.
>
> If you don't communicate the desired outcome and how you envision the
> product, the developers will still think - still invent - still come up
> with good ideas.  They just many not always be aligned with what you're
> trying to achieve.  If you're the product owner, and developers are
> coming up with what seem like irrelevant ideas, or pushing back against
> yours, don't argue with them - back up and make sure they understand the
> desired outcome, the users and customers, the product you're
> envisioning.  For teams I've worked with, it they still don't
> understand, I put them in a car (or in a plane) and go to the customer
> site to watch them work - to see the context.  They'll either
> understand, or be a little more cautious about being argumentative next
> time.
>
> I don't have any particular concerns one way or the other about the
> separation of product manager and product owner.  Luke Hohman describes
> the scrum product owner role as a "product engineer" - a more tactical
> and technical role than the product manager normally fills.  I get
> nervous when the boundaries between any role are two stiff.  I picture
> my team and company as a bit of a soup.  (stay with me here.)  I can cut
> up a bunch of vegetables and toss them in a bowl - and the boundaries
> between the carrots and the potatoes are still pretty clear.  But, when
> I add water and heat - the soup begins to boil and the boundaries get a
> bit fuzzy.  The edges of the carrots get a bit blurry - and the soup
> tastes a lot better than the bowl of uncooked vegetables.  If your roles
> have stiff boundaries, you're doing it wrong (in my opinion.)
>
>> I like this strategy, but I have a nagging suspicion that this is not
>> an Agile methodology. Shouldn't the User Stories be created in
>> a bottom-up fashion in Agile?
>
> If you mean by that that the team creates them: no.  I've seen some
> serious problems with the product owner and product manager not really
> understanding their own backlog.  Consequently they can't "steer" the
> project.  
>
> The simple steps you describe will likely work fine - but the devil is
> in the subtlety of how you do it.  I imagine Tiger Woods explaining how
> to play golf:
>
> 1. place ball on tee
> 2. select golf club
> 3. hit ball into hole
>
> It's simple see?   Anyone can do it.
>
> Thanks for posting,
>
> -Jeff
> -----------------------------------------
> Jeff Patton
> jpatton@... <mailto:jpatton@...>
> +1 801.910.7908
> skype; jeff_patton
> www.agileproductdesign.com <http://www.agileproductdesign.com>
>
> On Mar 17, 2009, at 9:18 AM, Jana Jecmen wrote:
>
>>
>> Hi All,
>>  
>> My company is developing the strategy for going Agile. Here is how we
>> plan to maintain the Backlog:
>>
>>     * product management should specify a "theme",
>>     * product owner should write User Stories for it,
>>     * developers should estimate them and eventually split them into
>>       tasks.
>>
>> This strategy is believed to give us a framework to stay on track and
>> to deliver what product management wants.
>>  
>> Did anybody apply a similar top-down approach in practice?
>>  
>> I like this strategy, but I have a nagging suspicion that this is not
>> an Agile methodology. Shouldn't the User Stories be created in
>> a bottom-up fashion in Agile?
>>  
>> I would appreciate your comments. Thanks,
>>  
>> Jana
>>
>
>
>
>

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

[Dan Harrelson-2]

Robert Fabricant was the speaker: http://library.ixda.org/node/3

...Dan

On Mar 18, 2009, at 6:05 PM, Jeff Patton wrote:

> I've recently been trying on for size the language used by a speaker  
> from Frog who gave a keynote at IxDA 09 (I forget his name...).  He  
> introduced the language output-outcome-impact
>
> output: is what we build
> outcome: is what happens in the world after we release our product
> impact: is what happens later - often much later.

[Jana Jecmen]

Hi All,

Thanks a lot for all the answers. They gave me a good insight. In particular
I want to thank Jeff Patton for the extensive replay - I feel empowered to
go out on a golf course and start playing golf now. ;-)

All joking aside, I am stating to get a better picture of how to approach
Agile methodologies and UX. It is very important to me since I am leading
the UX efforts at our company and shaping the strategies for UX in Agile
world.

Before I finish, I wanted to apologies for the poor explanations I gave for
my terms "top-down" and "bottom-up" - William, thanks for explaining what I
meant, you have guessed it absolutely correct.

Cheers,


*Jana Jecmen
*Senior User Interface Designer

*GEOSOFT INC.
**freedom to explore
*T +1 416.369.0111 #318
F +1 416.369.9599

Visit our site at www.geosoft.com



On Mon, Mar 23, 2009 at 12:59 AM, Dan Harrelson <danh@...>wrote:

>   Robert Fabricant was the speaker: http://library.ixda.org/node/3
>
> ...Dan
>
> On Mar 18, 2009, at 6:05 PM, Jeff Patton wrote:
>
> > I've recently been trying on for size the language used by a speaker
> > from Frog who gave a keynote at IxDA 09 (I forget his name...). He
> > introduced the language output-outcome-impact
> >
> > output: is what we build
> > outcome: is what happens in the world after we release our product
> > impact: is what happens later - often much later.
>
>  
>