Getting them READY: user story life cycle and “Epic Box” principle

I’d thinking to cover this topic long ago. This would be the start for the series of posts on PO work to “Get Them…” (user stories) ready, in and out of sprints…

I would like to start with describing what cycle user story goes through before it becomes READY for sprint planning meeting and how PO handles this cycle.

For sure there are many best practices to get stories READY and write proper stories. Instead of focusing on story-writing itself, here I will cover PO workflow to them ready.

So, here are my 5 cents…

Assumption: user stories are part of shaped big wish (called epic), that is part of Agile release/roadmap and takes place on “storymap” that had been presented to development team some time ago.

What does this means?

This would mean that:

• Value brought by an epic (and future user stories) is clear to everyone;
• Possible big “underwater” problems it may cause surfaced (reworks, performance, missing data, uncertainty, etc.);
• High level estimates are given to an epic;
• Big questions are addressed;

As next step PO prepares epic further, splits into particular stories, sizes each of them and “hones” acceptance criteria (aka satisfaction criteria). To proceed we need to know what does INVEST mean.

What is INVEST?

Things PO should keep in mind when doing story-writing and story-splitting is “INVEST” rule. It stands for:

• Immediately Actionable – so that team can start working on it immediately;
• Negotiable – so that can be quickly made smaller/bigger by removing/adding scope of acceptance criteria (AC);
• Valuable – so that everyone understands what value it brings to an end user;
• Estimable – so that it can be estimated with user story points or ideal hours;
• Sized to Fit In – so that estimates fit in established iteration length;
• Testable – so that has understandable and achievable acceptance criteria;

Splitting an epic

Then it comes to the split itself. I suggest doing the following way:

1. Have a pencil and paper talk  with your PO peer(s) on the epic before splitting:

• define overall description (As a WHO I want WHAT so that WHY);
• agree on the way to reach WHAT (draft acceptance criteria, aka AC);
• write AC down. You will end up having many AC, e.g. 30 or more;

2. Request, get and provide stories with everything that makes them immediately actionable (e.g. designs, data, clarifications, everything that has to do with 3rd parties, etc.);

3. Define story split logic, so that they all can be worked on quite independently and placed in a sequence that satisfy following criteria:

• upper stories do not require functionality of lower stories (and lower stories do not impede implementation of upper stories);
• functionality is split logically, trying to keep stories ~same size (remember, best sizing of stories is 3-8 user story points);
• upper stories allow user to see maximum valued functionality first;

4. Define each story description and split overall AC accordingly. Keep in mind that at this point new stories will pop up (I call them “conjunction stories”).  The rule is easy to understand.

Epic Box Principle: “As soon as you start emptying  virtual box of epic functionality, removing and shaping story after story out of it, you will find out something that is still there and was not your initial plan”.

If your plan was to split epic into 4-5 stories, you may end up with 7-8 or so. That is one of the reasons that explains why usually epic level estimates are smaller than sum of estimates of all corresponding stories.

Important hint: do not hesitate to split as combining is way easier. Splitting is good exercise because enforces to think through value->solution again and discovers potentially hidden problems, functionality etc. Another effect of splitting bigger stories into smaller is reducing doubt (and therefore risks) team will have associated with big story. It turns afterwards into saving user-story-points…
Therefore, it’s way better to have detailed backlog rather then let team estimate their doubt wasting story points on your inability to think through solution and side functionality that may popup during implementation of bigger chunks.
Remember: as PO you are in charge of what team does next and need to have stories prepared accordingly.

5. Peer review all stories with your colleagues after you consider them as READY to see what is missing, question how each AC may be interpreted, best guess on possible estimation;

6. Re-do steps 2-5 until stories are INVEST and  READY for sprint planning meeting (SPM);

To be continued … (“Getting them through sprint planning….”)

Dynamic Story Board: KANBANizing story map

“Imagination is everything. It is the preview of life’s coming attractions”. Albert Einstein

An interesting thought came to me while thinking on how to bring in dynamics in story map to make it a tool that will help PO both in day-to-day work/tracking and overall release management.

Key benefits that will serve this are:

• A full picture of upcoming product being built (within scopes of upcoming releases);
• Transparency about features are being worked on now/coming soon;
• Highlighting what features are READY and DONE;

To get the complete idea one needs to know the concept of story maps.

Combining this idea with KANBAN flow management framework makes a nice tool for PO:

Dynamic Story Board

So, let me explain what rows of it mean:

• Done row indicates stories that correspond to the functional areas of the product and are accepted by product owner in sprint review meeting(s), having story definition of DONE met.
• Areas row indicates key functional areas of the product as any story map has.
• Wip row indicates work-in-progress, e.g. stories that are part of the running sprint (that team committed upon);
• Ready row indicates stories that are ready to be presented to team according to definition of ready. PO moves stories in this row only if those compliant with INVEST rule;
• Pipeline row indicates all the stuff that is planned for the future. As you can see some stories are non-READY here for whatever reasons (not yet completed, or even bigger items (epics) that are not yet prepared for sprint planning and thus cannot be taken by development team);

NOTE: pipeline row can be splitted itself into several rows to indicate scope planned for releases.

This simple board will serve as Kanban-style board turned by 90 degrees CCW. You can always add rows that indicate whatever states your PO team will find beneficial. Such a board can be easily used by PO daily in managing both day-to-day focus on getting READY for upcoming sprint, while keeping an eye on overall priorities and backlog.

Here’s real-live example implemented:

Dynamic StoryMap LIVE