Hi Steve,
There is a video from a 2014 talk that I gave on this topic with
Brian Shoemaker for Agile New England here:
http://www.agilenewengland.org/index.php?option=com_content&view=article&id=313:agile-and-the-high-assurance-challenge-nancy-van-schooenderwoert-and-brian-shoemaker&catid=36:event-archives&Itemid=86
To respond briefly, I don't mean that you *have to* plan many
iterations in advance. I'm only saying that it's helpful to make a light
sketch of the way you (the team) see your features building over a few
iterations in support of a specific task important to your customers.
Jeff Patton's book on Story Mapping has plenty of examples.
It's a slippery slope from what I call a "light sketch" of the "key
features" to the old style ponderous planning stuff.
The original question asked for a way to revisit the usefulness of
user stories for a group of execs. In the above-mentioned video, we gave
a story map example in one portion of the presentation (about 15
minutes) and everyone could follow it and see how the use of stories
kept the project focused on customers' real needs.
If I were talking to execs in a medical device company, I'd use that
same example and walk them through it. If they are in a different
industry, I'd construct an example using a product and customer scenario
from their industry.
- Nancy V.
Post by ***@aol.com [SCRUMDEVELOPMENT]Nancy
I'm interested in the story map concept, but your description sounds like the old functional decomposition approach. It also sounds like a lot of upfront work, although I am sure it isn't. Can you describe the story map thing a bit more?
Thanks,
=steve
-----Original Message-----
Sent: Sun, Jan 3, 2016 4:16 pm
Subject: Re: [SCRUMDEVELOPMENT] User Stories Exercise/Game
Hi Michael,
My suggestion would be to have an exercise where you create a story
map with the top row of "cards" across being steps in the customer's
narrative. As an example, if the product is a medical device, the
scenario could be that a patient comes in for a treatment - then the
steps in the treatment delivery are across the top edge, and the rows
are the sprints.
That sets up the mindset that says "we are asking how the product
features can/ should support each step in the treatment scenario, as
well as the transition between those steps". I like the way it takes the
focus off the mere quantity of 'features' and puts it on the customer
experience for both patient and clinician.
If your customer will use your product in conjunction with other
products, this approach helps you to keep those interactions in mind
right from the start instead of as an afterthought.
It also helps everyone picture the way that partially-implemented
functionality can build over a few iterations to create more complex
features without too much confusion.
An example customer scenario from their industry might be a good
thing to try, depending on the timeframe for your exercise.
Hope this helps.
- Nancy V.
Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]I am leading Day 2 of executive training with my client. One of the morning topics is to revisit user stories. I want to drive home the point that user stories are about communication and shared understanding and NOT the âagile requirements.â I would like any suggestions as to how I might do that, especially if you can recommend and exercise or a short video. I had thought of using the origami game, but I think that may be too involved.
Suggestions?
Thanks.
Michael
--
............................................
Agile hardware? Yes! Agile safety-critical Embedded Systems too
Nancy Van Schooenderwoert, Lean-Agile Partners Inc.
US mobile: 781 301 1822 ***@leanagilepartners.com
Twitter: @vanschoo http://www.leanagilepartners.com
............................................