While helping through a transition with a PM and Dev team that I worked with on a daily basis, one of the major stumbling blocks I ran into was Release Planning and Roadmapping.  When I got there, they were in many ways using all of the right Agile terms, but not really following Agile principles – each release was meticulously planned out in advance, then chopped up into deliverable components that were split into two-week work increments.  In private, I often joked that they were using “AgileFall”.

However, we finally turned a big corner, and the breakthrough was a concept that I came up with during a lengthy discussion with the development manager and some of our internal stakeholders.  I’m sure it’s not “new”, but it was clear and concise enough that everyone in the room at the time was nodding their heads in agreement.  In short, I call it “What’s Now, What’s Next, What Else”, and I’ll share the core principles here.

• What’s Now refers to the work that the team is committed to doing right now.  We’re trying for no more than one major project in progress at any time for each team, so that they can focus on delivering that component as quickly, efficiently, and with as high quality as possible.  What’s Now is the focus of the team – it’s their deliverable, and they’re in charge of making it happen.
• What’s Next is the highest-priority work item at any point in time.  This can be fluid, though it probably shouldn’t change on a day-to-day basis.  The team and the Product Manager should understand this item and have it estimated to a high degree of clarity and confidence in the size of the effort.  As your What’s Now gets closer to completion, you’re going to want to (1) be ready to move What’s Next up to take it’s place, and (2) see What Else becomes What’s Next.
• What Else is the rest of the backlog.  High-level estimates, wireframes, themes and epics, this is where all of this resides.  The dev team probably shouldn’t be too worried about this on a day-in, day-out basis, but the PM team should be keeping a very close eye on what’s floating near the top, since at any time something that’s a What Else can quickly become a What’s Next.

The first objection that I heard was “How do we know what’s in a release?”  To which I replied, “Do we really know now?”  We had some pretty big scope creep and bad estimation issues in the past, which resulted in removing or de-scoping major features in order to achieve a release date.  My point in proposing this was that, when we start out a release, we pick a What’s Now for each team that we think will take 1-2 sprints to accomplish.  When that seems like it’s winding down, we take the What’s Next or What Else that fits the time remaining and put that in the queue.  Thus, we’ll have a very high confidence in what’s actually going to be released, while having the flexibility to adjust the plan according to (1) the time remaining, and (2) the priority at the time of “escalation”.

If it’s a What’s Now, it will be done; if it’s a What’s Next, it might be done; if it’s a What Else,
then don’t plan on it.

The second objection that I heard was “If we’re date-driven, how does this work? What if something takes more than a release’s time to build?”  This one is even easier to knock down.  You only take on a What’s Now that you can fit into the time remaining – at the beginning, that was three sprints for us.  If that takes two sprints to complete, then you only have room for one sprint’s worth of What’s Now to take on when you get there.  But, and this is the key, you know what you can and can’t do when you have to make that call.  No more promising a feature that gets bumped because something else was bigger than you thought.  If it’s a What’s Now, it will be done; if it’s a What’s Next, it might get done, and if it’s a What Else, don’t plan on it.

And, the last objection was “But [x] needs to know what’s going to be out in [y].”  This required some finesse – mostly, though, the response was “Do they really?  Do they need to know everything coming out in [y]?”  Which, in my past experience, isn’t the case.  Sales, Marketing, Support, Execs – they all need some vision into what’s coming, but usually that’s only the biggest and sexiest things that are going to be worked on, and I can practically guarantee you that these are going to be your first What’s Now items of the release. I don’t know that I got complete buy-off on this approach, but I at least have enough support to show that it’s going to work.

Roadmapping and backlog prioritization can be a huge challenge for a product manager trying to balance certainty with agility, and this process helps significantly, as does being open, honest, and transparent with these lists — having lists of What’s Now, What’s Next, and What Else are of no use whatsoever if stakeholders don’t have quick and easy access to the information, but that’s a topic for another time.