Planning on Jira dashboards could prevent an 88% failure rate
Tempo Team
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:
An agile approach, with adaptability and change built in
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, with a tool they probably haven’t considered: Jira dashboards.
When waterfall worms its way in like a weed
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.
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.
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.
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, you could install a digital whiteboard for Jira tool like Miro or Agile Planning Boards
. You could also consider using Jira dashboards for planning (more on this below).
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 work out before you create the project how your initiatives, epics, stories, and sub-tasks are all going to be organized in Jira.
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.
Planning on Jira dashboards
If you’re past the brainstorming phase and working with actual Jira tickets, then you might want to consider using Jira dashboards as a planning tool.
Most people view Jira dashboards as a reporting tool, something you use to monitor team progress on projects or sprints, or to look back at recently completely projects and sprints and see what worked and what didn’t.
But you can also use Jira dashboards for looking at completed and ongoing work and planning what you’re going to do next. One of our customers, CFAM, uses Jira dashboards for their sprint planning. On their dashboards they have charts and reports to visualize outstanding and urgent issues and who’s working on them.
That said, you won’t get far trying to plan sprints on Jira dashboards using only the native Jira gadgets. They’re too limited in scope, function, and customization. CFAM uses the Atlassian Marketplace reporting add-on Custom Charts for Jira to make their planning dashboards. With Custom Charts, they make dashboards that include the following:
2D stacked bar charts to show numbers of issues per assignee, so that teams and managers can ascertain who can take on work and who can’t
tile charts highlighting missed and upcoming deadlines to focus discussions on what needs attending to first
Issue lists with key details on outstanding issues.
Custom Charts lets CFAM filter the data down (using a separate gadget called Simple Search, which comes with Custom Charts) in order to home in on a particular assignee or set of issues. They’re also able to click on and open each issue in the Issue List if they need more information. These capabilities are particularly useful during planning sessions.
Planning as you go
Planning in native Jira isn’t easy, which is one of the reasons all the projects at my previous company were such a mess. Better planning using a digital whiteboard tool for Jira and Jira dashboards 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.
Jira dashboards and Custom Charts for Jira are excellent tools for planning as you go. You’d need to make and assign a bunch of Jira issues first, so I recommend starting planning in Confluence or using a Jira whiteboard tool for creating your Work Breakdown Structure and getting your project off the ground. Once everything’s moving, transition to using Jira dashboards and Custom Charts for planning and do what’s become so successful at CFAM.
What you’ll probably find is that, like CFAM, planning with the aid of some colorful and easy-to-make charts is loads more fun. And when something’s more fun, you’re much more likely to do it.
Sign up for a demo
Register
