The babushka story

Daishik
16 Aug 2023
0

You might have heard of the vibrantly painted, hollow, nesting Russian dolls, commonly called babushka or matryoshka dolls. They are renowned for revealing progressively smaller figures within them, with only the innermost and smallest doll remaining solid and unopenable.

In my years of experience within the software industry and Agile methodology, I've come across an analogous phenomenon: the babushka user story. Like the doll, a babushka user story implicitly contains one or more user stories. These may also be babuskha stories that also contain further user stories.

An illustration might help.

A feature is added to the backlog to capture a user's name, address and employment details and populate a new database. Several user stories are identified to deliver this feature. One might require creation of a user interface (UI). One might be to create the object models. Another to create the data access tier. Yet another to create the database. Some teams may be able to identify a lesser or greater granularity to this, depending on the application architecture or team capability.

Let's zoom in on our UI story. This story describes the necessary form fields and related UI requirements, with acceptance criteria detailing expected outcomes. However, within the acceptance criteria there's a stipulation that the user's details must be visible in the CRM system.

Notably, this is not a direct link or reference to a separate story detailing CRM integration. The implication here is that CRM integration should occur within the same delivery scope as the UI story.

In this instance, we've just found a babushka story: the UI story encompasses what should be a separate, fully-fledged user story for CRM integration. The developer who takes this story on is essentially committing to deliver two stories, UI and CRM integration, not just the UI.

Backlog refinement

A babushka story can appear quite innocently. User stories are intended, like good code, to be loosely coupled. But they are nonetheless related to other stories and features. So when a story is drafted, assumptions about existing or future stories may be made, with the intention to link them up in future updates prior to development.

The refinement process should uncover these babushka stories. Teams typically respond by separating out the nested story, clearly linking and contextualising both resultant stories. The extracted story will enter the backlog for prioritisation, analysis and review, unless it's simple enough to refine within the same session.

Teams can be pragmatic of course; if something is relatively uncomplex and will only introduce a minor detour in the delivery of the primary story, a team might decide to keep the babushka and retain it as part of the deliverable, perhaps with some additional clarification or a small uptick in the primary story's complexity score.

For anything complex though, splitting the story offers several advantages:

Preserving focus: The primary user story's deliverables and priority remain intact, unaffected by the inner stories
Prioritisation and analysis: The newly separated stories can be properly prioritized and analysed before advancing to refinement and planning.
Preventing chain reactions: We can guard against potential new babushka stories within the extracted stories.
Documentation: It ensures that the identified stories are documented on the backlog. Without this, our example CRM integration is merely a single point in the UI story, and it's delivery potentially causes an undocumented or insufficiently documented change to the codebase.
Parallel development: Separation allows parallel development by different developers or teams, optimizing resources.
Clean version control: Maintaining separate stories helps maintain clear version control and release notes.

The kicker for me is this: babushka dolls predictably have successively smaller dolls inside larger ones. There is also only ever one doll inside each doll at each level. That is most certainly not guaranteed when it comes to user stories. The intended outcome of what appears to be a small babushka user story could imply de-facto delivery of multiple stories, some of which might be more complex than the containing story!

What are the disadvantages to splitting stories?

Administrative complexity: Finding and splitting a story during refinement breaks the flow, introducing a kind of hiccup to the session. The original story needs to be clarified. Then one or more new stories needs to be created, each with it's own description and acceptance criteria. Someone has to do these tasks. Then someone has to analyse the stories, the PO has to prioritise them so they comes back round to refinement at a later session. In the meantime, any stories impacted might potentially be blocked from further refinement.

Therefore the only reasons why a babushka story may be tolerated is

Desire for efficiency: An effort to increase speed of development - or at least to increase speed to development.
Team instability: A lack of structural integrity in the team. It might be a dis-empowered or non-existent Scrum Master and/or Product Owner, or an over-empowered business or technical stakeholder. Either situation might drive a dilution of the operational processes, with the team seemingly unable to self-correct.

This is when babushka stories become deliberate. Perhaps a stakeholder thinks that the nested functionality is trivial and doesn't justify a story of it's own. Or it could be that they just don't want to create more stories because it's seen as a pointless administrative overhead.

At heart it's a well-intentioned effort to gain efficiency - an attempt to expedite development by compressing multiple activities into fewer stories, and therefore less time in backlog management, less time analysing, less time refining.

The illusion of speed

In my opinion and experience though, the gain in speed is an illusion.

Time that was apparently saved by not creating another user story is inevitably consumed elsewhere. The activities that are precursors to development still need to happen. Only now they happen during the sprint. They happen whilst the actual 'outer' story is supposedly being delivered. For all but the simplest babushka stories this inevitably reduces speed.

Additionally, those 'inner' stories risk never being adequately tested because they are only ever evaluated within the context of the containing story's criteria. After all, they lack acceptance criteria or documented requirements of their own.

In practice the babushka story development goes ahead with or without changes. The requirements evolve verbally during development, often without being properly appended to the user story. And it takes longer, perhaps even longer than the allocated sprint.

Embrace smaller, well-scoped stories

Regardless of how the babushka stories enter your backlog, if they survive to the point at which they enter a sprint they introduce risks and inefficiencies. My recommendation in general is to identify and separate these stories, ensuring smaller, more tightly scoped deliverables.

If a developer got run over by the proverbial bus whilst working the complex nested deliverable inside a babushka story, colleagues will find very difficult to pick up where he or she left off because so much will be undocumented. They'll find it unquestionably easier to pick up smaller, well-scoped stories.

Therefore given the choice I would always prefer to have five small stories in my backlog over one multi-faceted babushka story.