Re: Top-down User Stories

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: