I teach quite a few teams about User Stories. Most struggle with the concept, at least initially. One of the key challenges for many is the notion that stories are iterative. That you visit and refine them often, instead of the “once and done” view that we have for traditional software requirements.

Part of that revisiting is reinforcing the collaborative nature of the stories. The nature that says they are “intentionally incomplete” in order to encourage conversations around the story. Remember the : Card-Confirmation-Conversation, with conversation being the most important ‘C’?

I thought it might be helpful to go through a life-cycle example of how stories morph and change as they approach an execution-ready state. So here goes a somewhat contrived example—

Product Owner ideation of a few “stories” related to a new mousetrap. Call them “Epics”

Here’s the core Epic: As an exterminator, I want a better mousetrap, so my customers stop calling me in the middle of the night about ‘rodents’

1. Build a better mousetrap
2. Build a board level framework to support the mousetrap
3. Find the right “trapping” mechanism for the mousetrap; including high strength material

The product owner gathered this list from their constituents and stakeholders from a “back of the napkin” perspective.

At this stage, it’s just good ideas that need exploration and team-based analysis.

Backlog Refinement meeting #1

The Product Owner wants to get a sense for the “size” of these high-level epics from their team. At this stage, they might select a few specific individuals to help in the sizing, so as not to interrupt the entire team.

Since these epics are simply potential ideas, they want to assess their technical complexity and relative level of effort quite quickly. Investing as little time as possible, but still getting a “reasonable feel” for the work.

They use T-shirt sizing: S, M, L, XL, 2XL, etc. so that it’s fast. What’s different here is that the T-Shirt sizes relate to “Release Trains” or release chunks.

• A Small “fits” into a ½ Release Train (20 sprints)
• A Medium “fits” into a Release Train (40 sprints)
• A Large requires 2 (60 sprints)
• An XL, requires 2-3 (100 sprints)
• A 2XL requires 2-4 (100+ sprints)

After a relatively quick meeting:

• Story #1 the core Mousetrap is sized as an XL by the team.
• Story #2 – is sized as a Medium
• Story #3 – truly is said to be a “Research Spike” and is sized as a Small

The team moves on…

The Product Owner now has some very early, high-level sizing information to initiate investment discussions with their stakeholder team. Note that these aren’t commitments or firm estimates, but instead are high-level, informed guesses.

Off-line discussion: The team is intrigued by the XL parent story and starts to brainstorm how they might go about decomposing it.

1. Build the base
2. Build the bait mechanism
3. Acquire the bait and determine storage requirements
4. Build the triggering mechanism
5. Determine the performance requirements – speed, stun level
6. Determine the size of the mouse the trap can accommodate; no Godzilla mice allowed
7. Build the packaging for the mousetrap
8. Build the directions for the mousetrap; include “loading”, “setting”, and “cleaning” 😉

Question comes up about “cascading” mousetraps. For example, for truly infested areas, can/should they connect them together in a “defensive perimeter”? Clearly this needs more investigation.

Backlog Refinement meeting #2

The Product Owner has decided, with the stakeholders, that the mousetrap needs to be built. The following are some high-level clarity that has been added to the epic:

1. It needs to be built in one Release Cycle
2. It needs to be very simple – no Rube Goldberg solutions
3. It has to be sell-able in US, across North & South America, and Yemen
4. The materials can only cost $1.30 and the manufacturing cost needs to be keep to $.30/piece
5. Target price is $5.00 for the “Better, Most Reliable, Mousetrap”
6. It does not need to be “cascade-able”

The Product Owner asks the team to respond to this request with a story brainstorming exercise to gain a feel for the overall scope for a much more complete decomposition of the work.

Story Writing Workshop

The Product Owner reviews a presentation that represents the high-level vision and goals of the leadership team.

Instead of immediately diving into writing stories, the team starts brainstorming roles for the application. After some passionate discussion and debate, they come up with the following initial / primary roles:

• Rodent infested home owner
• Older home owner, trying to avoid a heart attack induced by rodents
• New home owner
• Pest service selling rodent removal services

Next they start writing stories. The roles are helpful in that they break up into smaller groups and brainstorm stories aligned with each role. The roles give them a different and more specific perspective than the simple “As a User” role would.

They also write the stories aligned with the key requirements from the stakeholders. In many cases, these requirements not only inspire functional user stories, but non-functional stories, infrastructural stories, and research spike stories. So there is a broad and deep mix created.

Here’s a sample of some of the spikes they think of:

1. Materials investigation, emphasis on pricing and meeting regulations.
2. Performance requirements: build a prototype and run experiments for:
   1. Size of the mice;
   2. Speed (spring material and tension) necessary to “stun”;
   3. How long the devices need to “retain” the mice.
3. The team wants to use a Java-based framework to build the overall trap and they have little experience with it. They need to “play around and learn”.
4. Material supplier and pricing investigation to ensure the expense requirements can be maintained.
5. And throughput is in question, since the target is “rodent infested”, what are the potential mouse/hour capture rates?

Wrapping Up

I hope you’ve enjoyed the story journey so far. In the next post, we’ll finish the journey.

One of the keys to effective story writing and story development is taking an iterative view to your stories. Allowing them to develop over discussions and time. Only trivial stories are written in one sitting. Anything else takes time to mature and grow. My hope is that this “series” shares that evolutionary process to you.

Stay agile my friends,

Bob.