In part-1 of this series we began the exploration of user stories from “concept to execution”. I wanted to show you how stories evolve as part of an ongoing Backlog Refinement process (and dialogue).

Here we pick things up…

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.

I borrowed this picture from Jeff Patton here –

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.