How Bad Planning Led to an 88% Failure Rate at My Last Company

It’s not hard to find examples of big, complex, multi-million-dollar projects that have crashed and burned.

From North Korea’s enormous, pyramid-shaped Ryugyong Hotel that’s still unfinished and empty despite construction starting in 1987. To the Ford Edsel, a perfect storm of poor workmanship, bad marketing, and out-of-touch project management that lost Ford the equivalent of $2.4 billion in 2020 dollars. To the two Death Stars launched by the Galactic Empire only to be unceremoniously blown up by the Rebel Alliance thanks to some bloody obvious design flaws.

Is it? Is it really?

For big, complex projects to succeed, two things are required:

  1. An agile approach, with adaptability and change built in
  2. Brilliant agile planning

In this article, I’ll explore how my last company couldn’t get to grips with either, and how that led to only 3 of my projects ever going into full production: a whopping 88% failure rate.

I’ll also reveal how project managers handling similarly complex or large projects can stop this from happening to them.

When waterfall worms its way in like a weed (ooo, wasn’t that lovely alliteration)

Before it was bought out by one of the best in the biz, I used to work for an agency that made augmented reality (AR) solutions. The world of AR solutions is pure VUCA, which stands for “volatile, uncertain, complex, and ambiguous”. Their projects involved putting a LOT of time and energy into exemplary and detailed user interface (UI) designs that were always at the highest end of the high fidelity spectrum.

But, even though they employed some of the best app designers in the Netherlands, not once did I have a project completed on time, within budget, or with a client saying at the end, “Yes, that’s exactly what I asked for.”

Why? Because even though they professed to be agile, using Jira and working in sprints, waterfall practices and sensibilities kept creeping in. In an agile environment, the devs should be busy prototyping and testing while the design teams are still finalizing their work. Alas, this was never the case. The huge amount of design kept precipitating similarly huge amounts of discussion and not enough action. These discussions would lead to the creation of mammoth Confluence documents full of long-winded descriptions of every app feature. And getting all the requirements documented before any actual development work is started is classic waterfall and the antithesis of agile working.

Failing to plan is planning to fail

All this waterfall-y documentation meant that when the time came to getting all these features into Jira, the project was already behind schedule and over budget, and the client less than impressed. At this point, because everybody was so anxious to get going, the attention to planning waned hard.

No one had time to formulate a proper Work Breakdown Structure (WBS), even though the WBS is vital to understanding what work is going to be done in each sprint. As a result, our Jira was a mess. Epics were used to represent versions, making the epics unmanageable, since versions are usually made up of multiple epics. Sometimes epics even got placed inside user stories, even though it’s supposed to be the other way around.

This chaos meant that although planning sessions took place with the best of intentions, none of the plans drawn up were adhered to. The project manager (PM) and the technical lead (TL) would do their best to perform backlog grooming and sprint planning in Jira. However, in a team where 3-4 devs were needed and there was only 1 (the employees were quitting like wildfire), projects would just start by themselves with no consideration for best practices.

To be fair, the tools they had for planning weren’t very optimal. The PM and the TL would sit side-by-side, looking directly at Jira. This isn’t that useful, since native Jira doesn’t have a dedicated space for planning. They could’ve used Confluence, but they never did. Sometimes they’d use a whiteboard or a flip chart. But, of course, this led to plans not getting captured digitally.

Without good agile planning, a VUCA project full of heavy research and development and unforeseen complexities is always doomed to fail. As they pretty much always did.

My 5 core lessons for agile planning

These are the 5 core lessons I learned about agile planning at my former company. Hopefully they will help you too.

  1. Remember that you’re an agile team, not a waterfall team. Don’t document every requirement at the outset, because those requirements will change. Only document the essentials. Agile documentation should be ‘just barely good enough’ and produced ‘just in time’. Agile planning involves limiting the waterfall-style planning at the beginning of the process and planning better once the process has actually started.
  2. Capture plans digitally. You’re likely to be using a work management platform of some kind, like Jira, particularly if you’re a medium-sized or large enterprise. This means your plans, even if you make them on physical whiteboards initially, need to be captured digitally, so that all those working in Jira can refer to them.
  3. Make plans IN the platform you’re working in. If you’re working in Jira and Confluence, make your plans in Jira and Confluence. Even though Jira has no dedicated planning facility, there are Atlassian Marketplace add-ons you can use, like Agile Planning Boards for Jira.
  4. Build a Work Breakdown Structure. A WBS enables you to plan well. Big, complex projects like VUCA projects need to be broken down into manageable chunks with a solid understanding of what those chunks mean and how they relate to each other. So in Jira, work out before you create the project how your initiatives, epics, stories, and sub-tasks are all going to be organized.
  5. Use your retrospectives to plan better next time. You won’t all be amazing planners straight away. The point of a sprint retrospective is to look back on your team’s performance, and how the project is going. Whatever you learn from these retrospectives you should use in your next planning session.

How could Agile Planning Boards for Jira have changed things dramatically?

Agile Planning Boards for Jira is an Atlassian Marketplace add-on that allows you to brainstorm, create Jira issues, and plan sprints and releases on a free-form canvas that’s synced with your Jira instance. You can use this canvas as a digital whiteboard, with sticky notes and diagrams. Or, if you still like using a physical whiteboard, just take a photo and upload it, and the app will stick an editable digital replica on the canvas. This enables you to capture your plans digitally without having to rewrite them.

Importantly, Agile Planning Boards lets you visualize the scope of a project and build that scope into a Work Breakdown Structure, which in turn can be worked into a prioritized backlog. This is where the Jira sync comes in. You can create and manage Jira issues, prioritizing them, estimating them, and assigning them, all from the canvas. You can perform backlog grooming and sprint planning by pulling issues from the backlog onto the canvas and visualizing them however you want (much better than staring at an endless list in Jira). And everything you do on the canvas will automatically reflect in your Jira project.

In effect, Agile Planning Boards acts as a visual overlay for your Jira environment, a dedicated workspace for planning that the PM and the TL at my previous company really could’ve benefited from.


Planning in native Jira isn’t easy, which is one of the reasons all the projects at my previous company were such a mess. Having a tool like Agile Planning Boards for Jira could’ve made all the difference.

That said, getting better at agile planning requires a mindset change, particularly if your projects have been suffering from “waterfall creep”, i.e. tendencies to do things in a waterfall-y manner even though you’re an agile team. We’re agile, not waterfall, for a whole bunch of very good reasons and project managers/technical leads need to focus more on “planning as you go” than “planning before you start”. This is where my previous company fell down.

Of course, if they’d had Agile Planning Boards for Jira, they might have been able to pick things back up again. That’s because not only is it easier to plan in Agile Planning Boards, it’s also a lot more fun. And when something’s more rewarding, you’re much more likely to do it.

Known as Atlassian’s resident #FunMan, Andy Barker has been an Atlassian Community leader for four years, founded their Community Events Rotterdam chapter, and was awarded the prestigious Community Leaders’ Choice Award at Summit 2020. Born and raised in the UK, Andy swanned off to the Netherlands after meeting a lovely Dutch lady and marrying her. He now lives with her, their two kids, cat, and horse, in North Limburg.