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 3’C’s from Ron Jeffries: 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?

Estimation

One of the goals the Product Owner had by investing in the story writing workshop was to gain a much more holistic view to the functional work associated with building the mousetrap. In other words, to convert those early stories and estimates into something much more finely grained and tangible with the team.

To that end, the Product Owner and the team establish another scale for estimation that is slightly more finely grained.

Again, T-shirt sizing will be used: S, M, L, XL, etc. will be used so that it’s fast. What’s different here is that the T-Shirt sizes relate to sprints:

  • A Small “fits” into a ½ sprint
  • A Medium “fits” into a full sprint
  • A Large requires 2-4 sprints
  • An XL, requires more than 5 sprints

The Product Owner and the team go through the entire list and estimate the stories. This gives the PO a more detailed sense of the level of effort to execute their current vision AND to start trimming things out to fit things into a single release cycle.

They still don’t know if that can be done, nor if the stakeholders will “buy into” the newly established views toward scope. But they continue to “chip away” at the work to better understand the scope, complexity, and overall level of effort. And of course, they include the entire team as much as possible as they drill into the details.

Why you might ask?

Because ultimately the team will be chartered with doing the work – so including them only makes good sense.

Eureka – Alignment

There are a couple of other techniques, probably with many variations, that help the team, Product Owner, and stakeholders align on the ASK vs. what’s FEASIBLE. First is story-mapping, where you align your hierarchical stories based on customer usage.

It would be like aligning Microsoft Word features based on the high level menu. In story-mapping, you start grouping your stories in clusters in the way in which your customer might be using them. Think customer workflows. What’s interesting about this technique is several-fold:

  • You start grouping stories into functional themes and prioritize the themes instead of the stories. This makes prioritization and planning easier.
  • It exposes any underlying requirements for infrastructure, architecture, UX, and any other “plumbing” needed to enable the higher level functionality.
  • It also is a great way to uncover dependencies that ultimately will need to be negotiated between teams.
  • It also helps in creating your products with MVP chunks that immediately begin resonating with your customers.
  • And finally, it puts the “customer first” in your discussions (or the persona’s first) if you will. So, it helps to keep a customer focus.

The other technique is release planning. Again, here we’re aligning stories according to project execution dynamics. I like to leverage both techniques because they each give me, and more importantly the team, different views towards the workflow for feature development.

Instead of going into the details here for release planning, I’ll point you to an article I wrote quite awhile back that explores the technique in much more detail.

Another nice reference for release planning is in the Scaled Agile Framework or SAFe. In SAFe, there is a periodic event called PI (Program Increment) Planning that is essentially the same thing as release planning. It’s an event where the entire team gets together to:

  • Decompose their epics into stories;
  • Layout those stories in time;
  • Negotiate architecture, design, and technical risk areas;
  • Negotiate internal AND external (cross-team) dependencies;
  • Negotiate quality and testing centric focused efforts.

And pull together a holistic “high level plan” that the team thinks is feasible and sound. If the stakeholders and the Product Owner agree on the effort vs. scope, then this “list” becomes the working Product Backlog for the team to begin actually sprinting and delivering meaningful chunks.

Ongoing Refinement meetings

You need to keep in mind that agile teams are constantly refining their backlogs. It doesn’t just stop at some discrete point. Instead, the stories are refined until they are ready for sprint execution.

So completing story-mapping and release planning, while a significant step forward for the team in getting their arms around a project efforts, is only the beginning. As the team starts to execute sprints, they continue to refine the backlog into more discrete chunks.

Quite often, they are not only looking within the current release, but if they’re mature, they’re starting to get their arms around the technical aspects of the next release as well.

Sprint Planning, Execution, and of course, Delivery

One of the first activities after release planning is to tee up your first sprint. All of the planning and estimation the team has explored so far are simply that…estimates. The team hasn’t delivered a thing yet and they don’t have a reliable sense for their velocity to compare back against the estimates.

So there should be a sense of urgency in any agile team to move as quickly as possible from “talking about” the work, to actually “doing” the work, delivering sprint work, and measuring their velocity.

The teams’ Definition of Done becomes incredibly important here as well, as it contributes to a stable velocity of the team consistently adheres to it.

Wrapping Up

My key goal in writing this article/post was to explore or show you the cyclical nature of the conversations that surround the evolution of user stories. The other missing piece is documentation. Often the agile community gets falsely accused of not delivering any documentation. And to be fair, there are many immature agile teams who don’t.

But nothing in the methods or the mindset is contrary to documentation and I usually recommend that teams keep notes of their conversations during the entire story evolutionary process. These are detailed requirements, but they ARE note surrounding clarifying discussions, critical decisions, and the why behind the story.

They also include the teams’ memory as I mention in this related post.

I hope your own mousetraps are developed iteratively, collaboratively and well.

Stay agile my friends,

Bob.

Comment