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