A three-level requirements hierarchy drives batch size up

Did you know that having a fixed number of levels for story splitting – such as the “Epic-Feature-Story” model popularized by SAFe – has an inherent tendency to drive batch size up? In this post, I present a short history of story splitting taxonomies in agile and demonstrate why three levels of splitting is not really enough. I also propose a remedy for the problem: allow for tree-like splitting for the highest level items, but go for cell-like splitting whenever “inside” a time-box.

– Avoid a complex requirements meta-model (Larman & Vodde, 2010)

In the later part of 2000s, authors and thought leaders in the field of agile software development started applying agile beyond the context of a single team, and at the same time, proposing requirements meta-models to better structure planning for a longer term than a sprint.

Some would say it all went south from there.

But for the sake of not hiding our head in the sand and pretending tree-like work item splitting isn’t already being practiced in every other company striving to become more agile, let’s suppose it would make sense.

Let’s first recount how the idea came about.

A short history of work item splitting

In the beginning, there was the product backlog. A flat list of what was seen as potentially useful for a team to do, with smaller and better understood items at the top, and bigger, more vague items at the bottom. The product backlog was taken care of by the product owner, refined together with the team, and with the team, the contents of the next sprint were selected.

Tracing back, before the notion of requirement abstraction models in agile software development, there came the notion of levels of planning. Rautiainen et al.  (2002) presented the first attempt at generalizing levels of planning beyond the context of a single agile approach (such as xP or Scrum). However, it wasn’t until 2005 until levels of planning in agile were popularized by Mike Cohn’s planning onion in the book Agile Estimating and Planning.

As an example, the picture below depicts different levels of planning. That particular picture is from 2012 and drawn by yours truly. In it I combined ideas from Smits 2007 and Cohn 2005. Based on a quick googling it has, verbatim, spread to become a popular picture to depict planning levels:

Progressive refinement of work items has of course been part and parcel of agile all along, But planning levels models do add structure to better understand work item splitting. In progressive refinement, as development proceeds, the bigger and still vague work items are split into smaller and smaller – according to the planning horizon in question. Often, large items split into smaller items that have “mixed priority”. Thus, when possible, splitting should proceed to identify just those small bits that add the most value. Then, only the most valuable “bits” should be implemented.

Tree-like vs. cell-like splitting

SAFe, the most popular scaling framework today – as well as many other authors on the topic before SAFe – propose a tree-like splitting model. In tree-like splitting you retain the original work items as well as the trace to the resulting work items.

To contrast that, early agile thought leaders such as the manifesto authors seemed to pay little attention to the notion of tree-like splitting. This is particularly well exemplified by the following excerpt from Mike Cohn’s book Succeeding with Agile (2009, p. 178)

After an epic is split into smaller stories, I recommend that you get rid of the epic. Delete it from the tool you’re using or rip up the index card. You may choose to retain the epic to provide traceability, if that is needed. Or you may choose to retain the epic because it can provide context for the smaller stories created from it. In many cases, the context of the smaller user stories is obvious because the epics should be split in a just-in-time manner.

Like Cohn, Larman and Vodde (2010) also prefer cell-like splitting. They propose that loss of context and ancestor information in cell-like splitting (where you get rid of the parent item) may be a speculative rather than a real problem.

Whatever the case may be, tree-like splitting has, largely because of SAFe, ended up popular enough to warrant a deeper discussion.

Tree-like splitting and work item taxonomies

With tree-like splitting often comes the idea that it could be useful to have a taxonomy – or a meta-model, whichever name you prefer – to refer to the different sizes of work items on the different levels.

The first such taxonomy I’ve come across – and coining of the term requirements abstraction model – was in a research paper by Gorschek et al. in 2005. In the years that followed, many different abstraction models by different authors, among them Dean Leffingwell’s Epic-Feature-Story, were proposed.

While for example Mike Cohn warns of the pitfalls of using “complicated” requirements abstraction models, it is not difficult to accept the idea that at least in some situations, having a taxonomy for discussing the items on the different planning levels would indeed be useful. Also, the little empirical research out there on the matter (for example the work of Gorschek et al. and Lehtola et al.) supports the usefulness of such taxonomies in the context of product development.

How many levels of splitting is enough?

SAFe’s requirement abstraction model has three levels: Epics (which do not fit into a program increment), Features (which should fit into a program increment but take more than a single iteration to complete) and Stories (which should fit into an iteration). While SAFe does not talk about having hierarchy inside these levels – perhaps to keep it simple – it has an additional term, ‘Capability’, to refer to a group of related features.

The authors behind LeSS, Larman and Vodde have recommended two levels at most, and in their 2014 book they were very clear on the matter: if you go for tree-like splitting, “a maximum of three levels is enough”.

But where does this number three come from? Why not two? Or four? Or five? How many levels are enough, and when?

To me it seems that sticking to three levels stems from historical reasons.

In the physical world of walls, post-its and index cards – where it all started – the notion of many levels of work item splitting certainly does not seem feasible. Indeed, a key goal of the manifesto authors – including those who came up with the concept of the product backlog in the first place – was to make a programmer’s life simpler. Perhaps because of that most of them implicitly advocate cell-like splitting.

In the realm of electronic support for work item management, tree-like splitting would certainly be feasible. However, implementing infinite work item hierarchies presents a considerable amount of usability as well as technical challenges. As a result, an overwhelming majority of electronic tools for work item management has not tried to actively divert from the flat list / cell-like splitting approach. Also, in those tools which have some sort of work item hierarchy, the higher levels are, instead of a true hierarchy, either like ‘glued’ on top of the existing model (think of JIRA’s Epics) or simply have a pre-set number of levels (for example AgileCraft).

Does fixed-level splitting drive batch size up?

It’s fair to propose that ‘three levels’ of splitting may be a legacy notion. Thus, the fact of the matter in how many levels of splitting would be enough remains an unexplored territory.

I personally question the need to limit the levels in the breakdown. This is because in my experience, fixed level splitting drives batch size up. And keeping the batch size small is undeniably one of the pillars for rapid feedback – which in turn is the heart of agile.

With fixed-level splitting, what happens is that you easily end up having items that are too big on the higher level(s) (the case where “nothing moves”) and/or items that are too small on the lower level(s) (the case where “business loses sight”). In my experience, you will end up with either scenario – or both of them. And they both effectively undermine the benefits being sought for with tree-like splitting.

Another, a more subtle dynamic which I’ve seen take place is getting ‘attached’ to the tree-like breakdown, and ignoring emerging new and possibly more direct ways to tackle the original problem. In such a case, tree-like splitting effectively drives towards waterfall-like thinking. It may also be that the “original problem” is discovered to be no more relevant, but because of the work breakdown and the attached governance mechanisms there is a tendency to simply keep going at it.

A tale of progressive refinement

But perhaps an example would illustrate this better? Take a look at this white paper: it presents a real-life tale of progressive refinement, which explains the dynamics taking place in detail. 

What to do about it?

Throughout the tale you were able to read of all the details that go on under the hood. While a three-level breakdown would have looked clean and simple, the progress made would remain invisible even though a lot of work both necessary and valuable was being carried out beneath the surface. Still,  with three levels, even the lowest, 3rd level items would in the example seem immobile. 

In the context of product development this dynamic most often manifests so that the gap between abstraction levels gets so wide that those ‘in charge’ of the higher level will lose grasp how the contents of the lower level relate to the overall goals.

In the same way, those in charge of implementing the lower level items may lose sight of “the why” – and missing that, it may affect “the how”, leading to sub-optimal solutions that would have been avoided had the big picture been in place.

What about metrics?

You may wonder that as the Story tree gets pruned and reshaped, isn’t information about what has been achieved in the previous PIs lost? If you reformulate the story tree in such a manner that the past achievements melt into each other or disappear, what happens to the possibility to draw burn-ups, burndowns, measuring epics’ and features’ lead time, progress and so on?

While most of the tools out there are not very good in supporting the merging and splitting of work items, there are tools which can retain the past to anguishing detail. Just last week in a workshop of a corporation’s RTE and their #1 tool expert, we tried to straighten out the configurations of a 5000 item story tree (done using JIRA Structure) to act so that when new items are created anywhere in the tool, they’d be sucked into the story tree to the correct place when the correct  ‘child-parent’ link is added.

Nearing the end of the time we had at our disposal, it was decided that the best course of action would be to ‘forget the past’ and rebuild a new story tree from scratch taking only the important items which are now or in the very near future to be acted along. There may be sentimental value in all the garbage collected over the years, but I’ve yet to see a case where it would have been needed later. Likewise, any possible metrics drawn from a heap of garbage items hold no value either.

Instead of progress metrics, aim for daily collaboration and value delivery

The key to successful iterative refinement – and indeed, agile – is in rapid feedback, value delivery and the daily collaboration of development and business.

When that works, detailed history, metrics and graphs – as well as the taxonomy for the items on different levels in the story tree ultimately matter very little.

Tree-like splitting needs more than three levels

The example in the white paper, while real, most likely a straw-man compared to the challenges you face in real-life product and service development. After all, while the domain here could be considered equally challenging, we can in theory deliver an end-to-end solution with a single person, and we already know what the end result should look like. We merely don’t know the exact steps to get there or how long it will take.

Just like tree-like item splitting helps you to avoid variability and batch size problems you’d have with a flat list, if you don’t allow for item splitting of arbitrary depth you’ll just run into the same problems a little later.

Allow tree-like splitting for work items outside a time-box

For tree-like splitting you need is easy reformulation of the story tree and as many levels you think you need whenever you need them. Most electronic tools don’t do a good job of supporting you there, so if you are going for an electronic tool, choose carefully.

But you don’t have to go for an electronic tool. If you allow yourself to ‘drop the past’ and focus on what is the plan right now, you can well do that with pen, paper and two walls. But how exactly, that will be the subject of a future post.

But still, in this straw-man example, using more than three levels seems very useful. This is why resorting to a fixed number levels will not be optimal in all but the most trivial cases. In fact is never has been optimal. I believe that is one of the reasons why the original signers of the manifesto for agile software development did not venture into that direction at all but swept it under the rug of ‘the product owner should take care of it’. Their goal was to make the life of developers simpler, and the only way they could see that happening was by fostering Business-Development collaboration on a daily basis.

And that’s what I have seen working as well. If you don’t have that in place, you are dealing with alleviating managerial phantom limb pain. And for that, fake metrics are just as good as the ones you could with a great deal of effort draw from the mess that is the stuff in your tool-of-choice.

Sure, you can in retrospect prune the story tree and force it into only a few levels. But during the process and in the collaboration, you need room to think and discuss. Constraining that discussion with a fixed set of levels and taxonomy of names and roles in charge of the levels will only be a hindrance and level s is hardly useful.

As you probably will have to deal with tree-like splitting, a final word of advice: what I’ve found useful is to allow for tree-like splitting for those items which are not supposed to be completed in a particular time-box. Using SAFe as an example, you’d allow tree-like splitting for Epics, but whenever Features or Stories are split, you go for cell-like splitting. Don’t go making a taxonomy for your Epics-on-top-of-Epics, it is hardly useful in reality. Too big is too big, and more gemba is what you really need.

After all, it makes little sense to have Features which are supposed to fit in a Program Increment – which have sub-Features which also should fit into the same Program Increment.

Or what do you think? As always, comments and experiences are most welcome.