Planning is difficult by itself, regardless of how well managed are the deadlines. One of the things that makes planning hard is prioritization and longer term perspective, which can get easily lost in the day to day work. Dealing with uncertainty is hard.

The horizon is always moving, so it’s far easier to estimate things that are closed and well known, and it’s very hard to project into the future. That’s why deadline-based approaches rarely succeed in terms of deadlines (even if they can work as a support to focus work on what really matters). This uncertainty means that it’s important to have a clear idea on the short term, but also that the long term has to be kept vague. Future planning has to be done and visible to everyone, but more flexible to change.

This workshop is a way to organize work for a specific team or project in a shared way. It assumes there’s a common, shared goal, and aims to define a roadmap to get there.

The ladder planning workshop follows these steps:

1. Context
2. Individual Planning
3. Ladder Placing
4. Milestoning

The time reference is based on a team of 6-8 people.

1. Context

30-60 min

Make explicit what are the user needs and goals regarding the project you’re working on, and possibly try to connect these with the business goals. If you have data, show and outline all the relevant data points.

The data can be provided in very different ways. Could be a brief presentation that touches all the relevant points, could be a specific group workshop activity like Pain/Gain or Empathy Map, or anything else that is able to provide the relevant context for the project being discussed.

This part is important to give context and frame the following discussion, so everyone has the relevant knowledge to support the discussion.

2. Individual Planning

15-20min

In the first part, give time to everyone, alone, to write down piece of functionality on post-its. The only rule here is: no talking. Everyone should try to get a plan down by themselves.

Each post-it should contain a single major or minor feature. It might be very concrete, or speculative, doesn’t matter since this can and will be designed, split or reviewed later. These features should all be user-facing. They all deliver value to our users.

Anything internal facing like architectural discussion, contracts, reorganizations needed should be noted, but it’s important to not be sidetracked by it. This step is exclusively on what value can be delivered to the user, how the project can help them to reach their goals, it’s not about how we get there.

The first part has to be time-boxed at 10 minutes to help people focus on the most important parts. Once that’s done, give 5 more minutes to prioritize all the feature post-its they have from the most important to the least important, from the most impactful to the least impactful.

3. Ladder Placing

30-60min

In turn, everyone should take their own post-its and place them on the wall, explaining what they mean with that feature. At this stage there’s no specific scheduling except just a timeline: a loose time indication left-to-right from this moment in time to the future. This means that left there’s now, and the more to the right the further in the future the task is.

The important part is that every post-it is placed strictly before or after an existing post-it.

If a post-it is very close or exactly the same as another one on the wall, that’s the only situation where it will be placed below it instead than left or right.

Note that discussions on each post-it here will emerge, and it’s important to facilitate the discussion there to be brief and aware of the task at hand, and to avoid to become a rabbit hole. There are lots of people and lots of post-its, so keep the conversation going (don’t be too restrictive) but at the same time help the group move on if it grows too much.

While the user value here is still the most important thing in each feature, it’s likely that everyone will now try to factor in elements such as technical feasibility and dependencies. This is normal, and it’s part of the prioritization discussion.

Once everyone placed their post-its, you should have a loose timeline, shared and agreed, between everyone in the team.

4. Milestoning

30-60min

Milestoning turns the sorted features in milestones, based on user needs. At this point you have the loose sequence of features on the wall, so you should then start to cluster them in milestones from left to right, from now to future.

You can do this by re-arranging post-its right there, or to create another separate timeline.

A milestone is defined as:

1. One major feature – no more than one
2. Smaller related features / bug fixes

Look at the post-its and label these clusters with milestones. Each milestone should have a clear label that identifies the major feature included in it.

For example we use the format: M1 ‘Tag’. The numbering helps with indicating its linearity in time, so it could even just be the public version if it’s a released software (v1.4), but the tag label is a clearer and easier to remember bit that reconnect with the major feature, so it’s helpful in communicating (i.e. “M1 Image Editor” or “M3 Multi Sharing”).

The end deliverable of this workshop is a list, from the most important milestone to the least important milestone. Each item in the list has an incremental number and a short tag label, and a one line description.

This workshop doesn’t look much but it’s very intense. Prioritization is hard, and it’s likely to lead to deep and difficult discussion. Also, the deliverable at the end of it doesn’t look like lots of work, but that’s exactly why it’s so powerful: it means that it’s now clear and simple enough to not look that overwhelming, which is exactly the result you want when you’re planning.

Thanks to the whole Automattic Hyperion Team and Richard Muscat.