A fixed-level requirements hierarchy drives batch size up

Have you recognized that having a fixed number of levels for story splitting – such as the “Epic-Feature-Story” model popularized by SAFe – inherently drives 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.

christian-bisbo-johnsen-38240-unsplash.jpg– 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 just happened, and 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 seen 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.

For example, recently I spoke with a development manager heading a 100 person dev organization with the tooling allowing for a three-level breakdown. They had about as many “Epics” as there were developers. Now how’s that for a landscape for the Business to prioritize?

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.

It also 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, and the same goes for stories.

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

A kingdom for a decent tool review

Backlog tools are seldom the first-order problem in an organization. And even the best ones can’t solve the first-order problems for you. However, bad tools do get directly in the way of your transformation efforts. That’s why it’s useful to tell one from the other.



– God bless me, but the backlog, is very like a list! (adapted from John Godfrey Saxe)

Having been involved in the development of a backlog tool (that’s Agilefant, nowadays known also as Nektion) since 2004, I’ve been a long time dismayed by the quality of the tool reviews out there.

I know, it’s individuals and interactions over processes and tools but bear with me here. Tools are seldom the first-order problem and even the best tools can’t save you. However, bad tools do get directly in the way of your transformation efforts. That’s why it’s useful to tell one from the other.

Unfortunately, most tool reviews seem to be camouflaged marketinghuge tables or lists consisting of extremely shallow observations of the tools’ capabilities and/or copy-paste from the vendor’s sites. I honestly don’t know why these are done in the first place! Perhaps virtual name-dropping gets you traffic?

Gartner’s magic quadrant reports seem to come the closest, but they, too, suffer from staying at a superficial level.

Another confounding factor is that as SAFe and the like spread further, the vendors’ marketing folk pick up that this is something their product should be able to do as well. And they go and change their website to say that surely their product supports SAFe whether or not that actually is evenclosely the case in reality. Of course similar things tend to happen to everything which has demand – like it has for AgileScrumLean or Kanban.

If there was a clear upside to doing good tool reviews, surely someone would have done so already. And kept at it, because whenever I have found something that might be useful, it’s cut short after some two posts.

So, while producing useful tool reviews will probably prove to be a futile effort in ways I don’t yet foresee, I’m willing to take my chances and try it.

But before going into the actual reviews, in this post I’ll lay some necessary groundwork.


In my experience, the “goodness” of a tool really comes down to three things:

  1. The conceptual strength of the tool
  2. How easy it is to get started
  3. To what degree you can tailor and adapt the tool as you learn more of what you need

I’ll try to elaborate a bit on what I mean by these below.


At the heart of the challenge is the concept of ‘product backlog’ and being able to support how it’s supposed to work. While that might sound simple – “just list the most important items” – taking a closer look at what has been said about it will reveal a vast landscape of needs.

Exploring that further would be a subject of another post itself, but you can get a taste of what I mean by skimming through chapter 2 of “Towards Agile Product and Portfolio Management”.


The ease of getting started is in direct contradiction to the conceptual strength of the tool. This makes things challenging.

I’ve seen cases where people want to start by getting a board-like view for the company’s high-level initiatives (a ‘portfolio kanban’, if you will). But equally crucial is the need to support a single team in its daily work.

While Trello might, with individual boards, cater to both of these needs, its conceptual strength stops short when people start wanting to combine these views into a coherent whole.

From the portfolio perspective this can expand into wanting swim-lanes for ‘strategic themes’, roll-upped progress metrics based on the epics’ breakdown and so on.

Likewise, on the level of the individual team, being able to tie the team-level work items to the big audacious hairy goals of the company is something that may help guide the decisions. As expert work such as programming is essentially problem-solving, and there are many ways to solve problems, an understanding of the big picture helps the team align their solutions to the company goals.

Either way, you have to start somewhere, and if the conceptual strength gets in the way of just jotting things down as you would on post-it notes or a paper notebook, it will cripple the drive.


To be able to combine both the easiness of getting started and the conceptual strength, you need to be able to adapt and grow the tool as you need to, creating new concepts and relationships and renaming the old ones.

This makes it possible for the tooling to grow with you. Otherwise, you have to force your way of working to the model enforced by the tool. This could be a “big hairy proven framework” which incarnates the latest version of the Unified Software Development Processes or Capability Maturity Models of late 1990s – or something else which doesn’t quite fit your reality.

No matter how enlightened, if a big model is forced on the organization too soon, the result will be co-optation: your system projects will be cast as ‘release trains’, your component teams as ‘feature teams’, and your non-customer facing business units as ‘value streams’. In such a scenario, the tooling wille become a strait jacket. In such a case, if you are going through with your transformation, not only will you have to change the organization, but also dismantle the tooling.

An important but fairly simple as well as often overlooked part of tailoring is being able to rename the concepts in the tool.

While choice of names will matter in the long-run (think of for example, ‘projects’ vs #noprojects), in a transformation you want to be able to pick your fights.

Will you, from the get-go, have to convince your C-level managers to talk of Epics, Sagas, Novels and Steam Trains or simply Business Value Proposals and Projects like they’ve used to?


At the time of writing this, I’m considering to take the following tools under a closer scrutiny; in alphabetical order, these are:

  • Agilecraft – the self-claimed leader which to date has not lent itself for easy sign-up and tire-kicking
  • Agilefant – the open source version from 2014 – as a baseline
  • Favro – the offspring of Hansoft from Sweden
  • Google Sheets – not because spreadsheets are that good but because they just might be better than anything else
  • Leankit– I’ve heard good things about this, though nowadays it has been acquired by the more traditional vendor Planview
  • CA Agile Central (formerly known as Rally) – first IPO, then going to CA to die?
  • Taiga – the other open source tool worth mentioning
  • Targetprocess – long-standing original thinking from Belarus
  • VersionOne – besides Rally, the other U.S. based ‘enterprise agile’ vendor; nowadays acquired by CollabNet, which already many years ago swalloved an early player, ScrumWorks

Of the obvious possible choices, I’m skipping JIRA, at least for now. This is because of my customer engagements. I am anyhow in the process of writing a separate thread of posts covering it.

I’m also skipping big software houses’ such as HP’s, IBM’s and Microsoft’s offerings, even though nowadays they, too, claim to support “agile”. I may be wrong in doing so, but for some reasons I can’t quite verbalize, I don’t feel it’s relevant to address them. And you can read how they by some strange mechanism get put up as leaders anyway from any Gartner or Forrester report.

So that’s it for the groundwork, and stay tuned for the first review. I will be backlinking the results to this post, and following Nitor on Twitter you’ll hear about it among the first.

If you have suggestions for tools which I should take a closer look at, or want to affect the order in which I go through the candidates, get in touch!

Scaling agile safe and sound

maatuska revefrsed.png

“Never argue with a fool, onlookers may not be able to tell the difference” – Mark Twain

Back in the day as researchers we pushed Agilefant forward with a versatile-model-first approach. While it lacked bells and whistles such as attachments or detailed user access rights, it had the concepts needed to support large scale agile already in 2007.

Fast forward to today, its latest incarnation is known as Nektion (the proliferation of the A-word tends to repel executives whose organizations might need it the most), and its entire ontology can be configured to fit the convoluted structures of large complex organizations you might run across.

Despite that, or perhaps because of it, I nowadays find myself rather agnostic with respect to whether agile should be scaled using frameworks such as SAFe, LeSS or DAD – or if it should (or even could) be scaled at all.

However, many of the lean/agile thought leaders out there do have clear opinions on the matter. If you’re in the process of “scaling agile” or considering it, my advice is that you should explore these opinions, and consider how the views expressed may or may not apply to your context.

To help you get started, I put together a table of some of the writings around the topic from the better known writers of the field I’ve run into. They are ordered starting from the most recent.

Many of the posts I’ve raised are critical of frameworks for scaling agile. Some are even critical about the notion of scaling agile in the first place. I made this choice because the organizations and people who are in the business of providing frameworks, tools and consultancy for scaling agile already cover the upside quite well.

By exploring the material below, you’ll hopefully become aware of the tensions around the topic – and thus are better able to steer clear of the potential pitfalls in your own transformation efforts.

All of the authors there are surely worth following, and to dig deeper, check out also the commentaries of the posts linked below.

Author Post Quote
Dan North (2018)
In praise of SWARMing Scaling methods are not unhelpful per se, rather that they are neither necessary nor sufficient for successful transformation.”
Duncan Nisbet (2018)
SAFe systems thinking? “The cultural aspects […] are the overriding blocker to systems thinking. Merely talking about it briefly in a 2 day workshop is not going to overcome that challenge.”
Renee Throughton (2018)
Why SAFe is not the scaled approach you need “It encourages massive batching […], old world thinking on estimation […], doesn’t change leadership behaviours [ …], doesn’t force a change in organizational structure”
Marty Cagan (2018)
Revenge of the PMO “If you were an old-school PMO missing your classic portfolio, program and project management, you would probably love it.”
Steve Denning (2017)
What is Agile? The four essential elements “The emphasis […] is more on descaling big complex problems into small pieces than on scaling up the organization to match the complexity of the problems it is dealing with.”
Mike Cottmyer (2015)
Let’s acknowledge SAFe for what it is…and move on “You either create the conditions to do Agile well—Agile as it was defined 14 years ago—or you do something else. That something else is called SAFe.”
Jacob Creech (2015) @JacobCreech SAFe: How I learned to stop worrying and try the Scaled Agile Framework “Suffice to say, I have a reasonable perspective on SAFe in real life, which I prefer to the typical theological debates that arise when SAFe is discussed.”
Ari Tikka & Ran Nyman (2015) @aritikka, @ran_nyman Scaling Agility or Bureaucracy “Good consultation often helps to get results, also with SAFe. However, there is the risk that the systemic conditions are not changing, and the change remains superficial.”
Kristian Haugaard (2015) @haugaards Interview with Dean Leffingwell about SAFe “Many of [reviews of SAFe] have been written by authors who never spoke with anybody who had been involved in a SAFe implementation…”
Ari Tikka & Ran Nyman (2015) @aritikka, @ran_nyman LeSS-SAFe comparison “[Both LESS and SAFe use Nokia as a reference, but] LeSS was and is mostly used at Nokia Networks […] while SAFe was mostly used at Nokia Mobile Phones”
Jeff Sutherland (2015) @jeffsutherland Q&A with Jeff Sutherland on Agile Leadership “scaling frameworks are often used to provide scaffolding for the legacy organization until they can evolve”
Ron Jeffries (2015) @ronjeffries Dependencies, Scrum of Scrums, and SAFe “[…] a huge fraction of the dependencies between teams are artificial. They are due to poor allocation of work from above, and to the existence of unnecessary silos of responsibility.”
Mike Cohn (2015) @mikewcohn You Don’t Need a Complicated Story Hierarchy “When teams are forced to use complicated taxonomies for their stories, they spend time worrying about whether a particular story is an epic, a saga or merely a headline.”
Sami Lilja (2014) @samililja The case against scaling “The problem is NOT that we lack ways to scale agile. The problem is NOT that we fail with agile in large organizations. The problem is that we are large. […] The frameworks take “large scale” as given, and do very little to reduce that.”
Lyssa Adkins (2014)
The Agile Coaches’ Coach Shares Her View on SAFe “Rumi urges us not to become too attached to one “grain”; one teacher or one way, or, in our world, one agile framework or one perspective. I urge the same. Rather, let us look out wider and farther.”
Mike Cohn (2014) @mikewcohn Introducing the LAFABLE Process for Scaling Agile “some of [scaling approaches have been] even tested on real teams before the marketing machinery spun up to promote them”
Ron Jeffries (2014) @ronjeffries SAFe – Good But Not Good Enough “SAFe is good. It’s just not good enough. It provides some benefit, but endangers an organization’s progress toward really high functioning”
Ron Jeffries (2014) @ronjeffries Issues with SAFe “Release Train is an example of a remedial practice presented as an ultimate solution. […] SAFe does not push hard to eliminate the problem: it just gives a way to accommodate it.”
Peter Saddington (2014) @agilescout The Scaled Agile Framework (SAFe) – A Review “thoughtful and well-intentioned [but] takes it a bit too far and defines […] almost too much”
Charles Bradley (2014) @ScrumCrazy Is SAFe(tm) Bad? Is it unsafe? Is it Agile? Are there alternatives? “To date, no Agile Manifesto author has endorsed it. That should tell you something right there.”
David J. Anderson (2013) @f4p_dja Kanban – the anti-SAFe for almost a decade already “in 2003 I decided to focus on […] reducing or eliminating resistance to change. A process-centric focus wasn’t working without a lot of money, positional power and fear to motivate individuals to fall into line.”
Amr Elssamadisy (2013) @samadisy Is it safe? “The question is not whether SAFe should be used as the strategic basis for large Agile adoptions. The question is this: What will make those adoptions most successful?”
Ken Schwaber (2013) @kschwaber unSAFe at any speed “The boys from RUP are back, […] partnering with tool vendors. […] Consultants are available to customize [SAFe] for you, just like RUP”
Neil Killick (2012) @neil_killick The Horror Of The Scaled Agile Framework …” a horrible, money-making bastardisation […] of Scrum, Agile and Waterfall…”

P.S. Curiously enough, I was not able to find posts of sufficient depth, quality or otherwise of interest (subjectively, of course) from 2016. But surely there are some lying around! Can you point me to any?

Culture follows structure


– Culture is the product of the system; change the system and behavior changes
(John Seddon)

As a community, advocates of agile often seem preoccupied with the notions of culture and mindset. Even when people who have been involved in successful transformations actually talk about structural changes, they tend to refer to it as “changing the culture” – for example in these presentations by Mirette Kangas and Fred George.

This emphasis on culture paints the picture where “if you just change hearts & minds and train everyone, self-organization happens and things fall into place”.

My journeys in enterprises have taken me to places where seemingly everyone was trained in “agile” but as the key structures remained unchanged, the impediments persisted.

In one organization, “Done” did not mean that something was deployed and running in production. Done merely meant that the feature had been handed off to the Q&A and release organization. And as there was no easy way to measure the time in the Q&A and release phase, they measured the time spent in the development phase and called it the ‘lead time’. As we pointed this out and went on to explore this further, we discovered that for features that had been developed in 1-2 months, the total lead time could be as long as 18 months.

Another common example of a structural problem comes from contractual issues. In one organization, the people were excited about the new ways of working, and most had been trained as well. But upon asking if they could mix the current, component based teams to form cross-functional feature teams, the answer was a disheartened sigh.

After a bit of prodding, it was revealed that because of the outsourcing contracts in place, this was considered impossible. Moreover, the outsourcing had resulted in a considerable amount of offshoring. This had led into people on different sites specializing further into certain kinds of tasks. Because everybody had to have something to work on, prioritizing according to highest customer value was not possible.

And as the people who were responsible for the contracts did not feel the pain, nothing was done about these issues when the contracts were eventually renewed.

You cant’ change structure bottom-up

Organizations tend to grow so that when problems occur, specialists are hired to take care of them. Over time this results in organizing such specialists into their own resource pools. Then work gets done by handing it over from one pool to another. Such structures are in direct contrast with the notion of cross-functional feature teams and organizing around delivering value to the customers.

In my experience, the drive to adopt agile often arrives at organizations at the level of development managers and team leads. However, the prevailing structures can only be changed by C-level executives, and hiring a “VP of agile” will not be enough.

Take it from the thought leaders

It doesn’t help that currently the most popular framework for scaling agile, SAFe, is not that explicit (at least compared to the total amount of material in the framework) of the need to change the structures. Examining the structures lurks under the notion of “applying systems thinking”.

To me SAFe has seemed almost surprisingly agnostic about the matter as it allows “development value streams” and says that “there is no one right answer”. The fine print does warn though that with development value streams you will end up with a lot of dependencies.

I had the chance of discussing this with folks from Scaled Agile Inc. They consider it a conscious choice: it’s better to get a foot in the door and then proceed to help the client from there instead of getting completely turned down as a result of proposing radical changes up front.

While that may be true, there are thought leaders who criticize SAFe from SAFe from the point of view that because of the sheer amount of material, it can easily turn into scaffolding for the legacy organization to hide behind.

Also some thought leaders have taken the notion of changing the structure as a central part of their teaching. In fact, they consider the preoccupation with culture as failure demand caused by the inability to change structures.

They articulate this so well that I’ll step aside here and provide a few pointers so you can delve deeper into the matter.

The ones I’ve raised here work quite well even if you only listen to the audio, so you can explore them while for example commuting. These speakers have also lot of other presentations available on Youtube which further deepens the point. Here’ I’ve tried to pick those presentations that most directly cover the point I’m trying to convey and put them into an order they are most easily approachable. Enjoy!

Four presentations worth checking out


Author Presentation Quote
Mike Cottmeyer (2017)
Is culture really the issue? (Youtube, podcast) “Most organizations are deeply flawed from the perspective of delivering value. Teaching them to want something is not enough. At some point you have to do the work of removing the impediments. And if the impediment is 2M lines of legacy mainframe code in a key business system, you just fix by the next sprint”
Craig Larman (2016)
More with LeSS: a decade of descaling with LeSS @ Agile Munich meetup (Youtube) “I can quickly spot a young naive change person when they say you have to change culture; you can’t change culture”
Jason Little (2017)
Rethinking agile transformation (Youtube) @ Agile Montreal “Co-optation is the most common mode I see. A VP of agile is hired, the structures persist, we do things as we always did them, and the agile is put in front of everything.”
Dan North (2017)
How to break the rules @ Goto 2017 (Youtube) “In companies we have a huge number of rules to cope with the limitations of the old way of working. In a transformation we not only have to dismantle them but also come up with the new and mostly very different kinds of rules to manage the new limitations”


The simplest way to run SAFe with JIRA

Ship in a Bottle Seute Deern 1

“Going agile with JIRA often looks like learning to sail with a ship you’ve built yourself – in a bottle” – Dr. Agilefant, 2016

Somewhere in your large, complex organization there are people who think you should strive for a more agile way of working. Some of those people may think that the Scaled Agile Framework (SAFe™) could be a good blueprint to follow.

While there are alternatives, let’s suppose you want or have to use your existing JIRA to support also the new way of working.

Mismatch of models

SAFe is less complicated than it may seem at a first glance. The difficulties stem from JIRA’s conceptual model, which does not match what is suggested by SAFe. On top of that your organizational design and/or constraints posed by your suppliers or customers probably do not match the set-up suggested by SAFe either, but that is the subject of another post.

JIRA natively has a three level requirements abstraction model (Epics, Stories and Sub-Tasks), but the terms are not configurable. Sure, you could define new issue types with the proper naming, but the terms in the UI will remain the same. This means that at least some mental mapping is required from the users. And of course, a three-level work item breakdown does not scale to a four-level SAFe.

In addition, JIRA’s single level non-nested work containers (Projects) means that at least some workarounds will be needed to express SAFe’s levels of planning.

Typical pitfalls

JIRA originated as an in-house bug tracker. It’s first commercial release was in 2002, and while plenty of features have since been added, little has been taken out. While this makes JIRA highly configurable, it is easy to go overboard in terms of the workarounds.

A common pitfall we’ve seen is that prevailing impediments to agile such as a function or system based organization are replicated into JIRA as some key concept – typically as Projects. This further cements the existing structures – which in most cases should be dismantled and rebuilt around customer value delivery.

Another common challenge stems from attempting to overcome the limits of JIRA with plug-ins. While this is possible – to a degree – it leads to a more complicated set-up. And even with a willing, SAFe-trained organization and detailed instructions, the supposed way to use JIRA can prove too complex to grasp.

The result is a constant demand for training to grasp the complicated JIRA-with-plugins set-up. People also simply go around the complicatedness and make up their own special ways of using the tools, which makes progress roll-ups difficult and improving the ways of working via measurements impossible.

Resorting to ‘shadow accounting with MS Excel’ is also fairly common solution even in cases where JIRA is seemingly being used.

The simplest way

In matching SAFe and JIRA, you have to make some compromises. You should strive to avoid design decisions that directly get in the way of the transformation. You don’t want to simultaneously deal with both the resistance to the new way of working and the complicatedness of the desired JIRA usage model.

Having observed JIRA usage in a number of organizations striving toward large-scale agile we have devised a blueprint for how to implement ‘three-level’ SAFe (known as ‘Portfolio SAFe’ in the 4.5.1 version) using JIRA.

We’ve deliberately aimed at the simplest possible model doable with plain vanilla JIRA. While it is by no means perfect, it presents a sane starting point. The mapping of the key concepts is described in the table below.


SAFe concept JIRA concept Notes
Portfolio Project JIRA’s projects have no beginning or end, and they are the highest level wrapper of content
Epic Epic Workflow: funnel, review, analysis, backlog, implementing, done
Feature Custom defined issuetype ‘Feature’ Use JIRA’s native ‘epic link’ to connect Features to Epics. Workflow: funnel, analysis, backlog, implementing, done
Story Story Use the child-parent issue link to connect to Features; workflow funnel, backlog, sprint, done
(Bug) Bug Use the child-parent issue link to connect to Features; workflow funnel, backlog, fixing, done
Strategic theme Label Manually add at least to Epics; and then to the depth deemed relevant
Key system being worked on Component Add components to the depth of the work breakdown you have sibling work items which concern different components
Team, Train, Solution, Portfolio A single JIRA user for each party Multiple people use the same login. Everyone should have access rights to ‘everything’ except admin functionality
Portfolio kanban Kanban board One for each portfolio
Program kanban Kanban board One for each train; program increments are not explicitly modeled; Features in the status ‘implementing’ are considered to be in the current program increment
Team board Scrum or kanban board One for each team, according to their preference
PI Objective Online shared spreadsheet Not because it’s are good but because it’s better than what you’ll hack to JIRA – especially from the business owners you’ll want to get engaged.

Also, spreadsheet works better than JIRA for the most important metric suggested by SAFe – program predictability based on PI Objectives’ achieved business values

Evaluating the design choices

The choices made above come with good, bad and an ugly side. The Good is what we see as the upside of the choices, and The Bad as the downsides which we see that can be overcome. The Ugly refers to those downsides which are inherent to plain vanilla JIRA and can’t easily be worked around.

The Good

  • Very little mental mapping required; JIRA concepts are not forced to represent other things than their name implies
  • User per party and no access restrictions support the notion of shared responsibility and promotes the importance of frequent communication
  • Can be moved to in an existing JIRA set-up; changes are restricted to a single project and new ‘party’ users
  • Possible with plain vanilla JIRA
  • Not necessary to use JIRA’s rather convoluted sprint functionality
  • Virtually non-existent licensing cost (only a handful of user seats required)
  • Frees the parties to organize as they wish as a team (do more detailed coordination on a physical board, work as a mob, and so on)
  • Changing the legacy organization structure based around systems is a key challenge in most organizations; including this reality via modeling systems explicitly as Components can be leveraged to spot and eliminate dependencies as well as problems with the current organizational design

The Bad

  • Unconventional design choices (compared to how JIRA is in my experience commonly used) may cause resistance in moving to the model
    • No user per a living person
      • However, the model does not fundamentally change if the team-user is replaced with a person-user; you can still model the teams and trains as groups and use these in queries
    • No detailed user access control; everything is shared;
  • To leverage strategic themes in querying lower level items, you’ll need to add them by hand all the way to the story level
  • JIRAs label editor (or rather, the lack of one) makes the usage of Strategic themes error-prone
  • One might argue that having ‘Bug’ as its own issue type is against the grain of ‘the simplest thing that might work’; however, our experience is that sooner or later you’ll want to be able to discern between fixing and enhancing based on work item type; this also frees using labels for other purposes

The Ugly

  • Plain vanilla JQL is not powerful enough to support many queries which can be seen as interesting to running a SAFe-like process; in a future blog post will show what exactly I mean by this
    • However, the most important metric of SAFe has to do with PI Objectives and those we suggest should not be in JIRA at all
    • Also, the plugins required to ease the needed queries and detailed filtering work around the most critical issues are relatively inexpensive; we will take a more detailed look of this in a future post
  • Hard typing of requirements and no support for N-level work item splitting and; why you would want to avoid the former and have the latter is the subject of another (rather long) post by itself; but it has to do with the heart of agile requirements management – iterative refinement and keeping the batch sizes manageable
  • Program boards with dependency visualization can’t be done with plain vanilla JIRA; I predict sooner or later someone will do a free plugin compatible with Cloud JIRA

Running the model

We are running a model very similar to the one described in a couple of customer cases. In the future we will be writing about for example how PI and sprint plannings work in this model, and also present a set of example queries to questions commonly asked by the key SAFe-org stakeholders (such as ‘show me all the work related to this epic’ or ‘show all the work related to this strategic theme).

To be among the first to get the link, follow @dragilefant on Twitter or LinkedIn or @NitorCreations 

To be among the first to get the link, follow Nitor on Twitter or me on LinkedIn.
And should you be running something similar – or even try this model out – we’d very much like to hear of your experiences.

Top ten lean and agile presentations on YouTube

As the year begins, it’s time to reflect on what we’ve learned during the past 20 years of the things we today call lean and agile. I’ve compiled a top list of lean and agile presentations which to me have been especially intriguing and inspiring. The presentations are not in any particular order.

Nowadays most of us have a lot more ear-time than reading time. So just plug in your wireless headphone and dig in, whether you’re commuting, doing the dishes or something else where your brainwaves could use a little simulation. If you happen to drive a motorized vehicle while listening to these, be sure also to look at the road ahead instead of the slides…

Best of 2018 to everyone!

Fred George @ Goto 2015: The secret assumption of agile

“In the 70’s we could code together with the customer. As the industry, the companies and the projects got bigger, we told the customers to go away, as the coding now took a little longer time”


Jeff Patton: User story mapping

“Do you think they’re using Jira for planning at Atlassian?”

Jeff Patton Digs into the concept of user stories, how to use (and not to use them)


Chet Hendrickson and Ron Jeffries: The nature of software development

“SAFe certainly is scaled, and it most certainly is a framework”


Bob Martin: The future of programming

In 1938 Turing described the modern computer. Three years later, he found himself cracking signals with an ancient machine. Kind of makes me think of the bug tracker I’m driving the folks to use in order to manage the building of their next generation whatever.


Allen Holub: #noestimates

How many man-hours was a story point, again?


James Coplien: How Agile and OO have lost their way together

“The Japanese fooled Americans into looking for root causes in complex adaptive systems”


Woody Zuill: Mob programming – a whole team approach

“With mob programming, most of what destroys productivity just faded away in our case”


Joshua Kerievsky: Modern agile

Modern – or perhaps agile how it was all along, as compiled for the contemporary audience.


Bas Vodde: The Story of LeSS

How to solve dependencies and why in practice it can be hard to tailor a big framework method down to your organization


Craig Larman: Practices for Scaling Lean and Agile Development

The competitive contract game, component teams and the prerequisite for scaling agile