Aside from the nuts and bolts feature development of a software project, which I believe is best handled through agile sprints, there's often a lot of other actions and dependencies which this exercise helps to map.

As the Product Vision starts to become clear and thoughts turn to implementation, I've found real value in this exercise.

What problem does it solve?

The group's sense of a forthcoming project is at either extreme ends of a spectrum:

• some believe it's a simple project and we don't need to capture the actions, we just need to get on with doing
• others are overwhelmed by the sheer volume of different actions and dependencies they think lay ahead

Good agile is about shared understanding and this exercise creates an artifact for capturing where we're really at with the non-dev elements of our forthcoming project.

What is it?

Based on the classic Critical Path Method but not as prescriptive about task durations, my approach is just to try and get the shape of the project mapped out in colourful blocks.

Each block is a task or decision. But to be very clear, I'm not talking about the tasks involved with product development. These should be raised as stories and handled within the sprints.

I usually put a looping set of blocks at the heart of this diagram representing the product development sprints. Leading into that bit are all the things we need in place before we start. Coming out of it are all the actions which come after we declare we've 'done enough' for this phase.

How do I create it with the team?

1. After the Product Vision is agreed, I'll get the whole project team together and depending on the setting we'll use post-its or a digital tool like Miro to capture everyone's inventory of the tasks and decisions.
2. Get all the notes organised together and do some rough de-duplication and grouping.
3. As a group we see if there are any obvious dependencies or blocking relationships that are worth noting.
4. After the session, working alone and focused, I use the collaborative notes to inform diagram with lines to show the actual dependencies. You can then add in any other tasks you know will need to happen such as testing stages, meetings, information from key people.
5. This is just my sense of it based on the conversations in the room, so validation is important. I get the group together again for a much shorter session to walk through the plan and make sure nothing has been missed or misunderstood. At this stage the final diagram can be edited on screen as we make decisions about the flow.

How do I use it?

Firstly, share it with all the project's stakeholders so that they can see what lies ahead. They will ask where things are up to repeatedly and so show them, visually. There's nothing like seeing 'you are here' on the map.

As the plan changes - because let's face it all plans are wrong - then update this path to reflect your changing understanding of what's going to happen. Keep it as a living document, share it regularly and use it to both spark discussions about the way forward as well as capturing the decisions you make together.

As the tasks and decisions are completed, I find it rewarding to change the colour of the tasks or add checkmarks. This then gives a lovely graphical way for everyone to see that progress is being made and what can be done next.

This is a real one I used to keep One+All colleagues updated as we progressed the initial My Account MVP project back in 2021:

What's the real value?

I like this Simple Critical Path tool because it's great at flushing out aspirations and concerns people have. You find out way more than just what needs to be done.

It's also great for visual learners like me.

As long as you recognised that it's never finished and final, that it's a support for shared understanding rather than a replacement - then this is a worthy tool for your agile kit.