Communicating Agile Roadmaps

I worked in many industry verticals in my career – transportation, maritime, energy, renewables, logistics and chemicals. In all these verticals, I faced the challenge of balancing an agile roadmap and communicating the dynamic nature of software tools. Most of the businesses that I serviced wanted to have a very “predictable” future.

Conversations with customers always went along the lines of:

• “Can you commit this feature will be available in release X?”
• “I can see this feature popping up in 7 months, are you sure you will be able to deliver?”

By the way, this is not a criticism of these companies. I worked mostly with advisory software tools and many of our users were working in safety-critical environments. In the risk management world, a feature can make a lot of difference when offering advice to a consultant/engineer. ?So, it is important to have some level of predictability!

However, there are many constraints in managing agile roadmaps – new requirements, new customers, big contracts, changes in the technology stack, uncertainty around development and QA. Plans rarely go according to plan ??

So, I designed a way to communicate agile roadmaps. We started by breaking down our roadmap into four stages:

• Firm: Detailed development items with minimum variability to the plan
• Confident: High-level overview of development items with low variability to the plan
• Flexible: Development themes with an overview of epics with a great level of variability in the plan
• Fuzzy: Development themes, great variability on the plan

From an operational perspective, our timeline looked like this:

In our “Firm” stage, we tried our best to operate with at least two well-defined sprints (i.e. one month ahead).

“Well-defined” means:

i.????We knew exactly what development items we wanted to work on,

ii.????They were estimated to the best of our ability, and we knew the work would fit in two subsequent Sprints,

iii.????We had a well-defined test strategy and,

iv.????There was a bit of room for innovation/quick wins

In practical terms, we also had well-defined and well-documented user stories, unit tests, bugs, features, with acceptance criteria and testing plans. We allowed for little variability (measured by a KPI that shows how many story points we are adding mid-Sprint).

In our “Confident” stage, we had a high-level idea of what we wanted to develop over the next six sprints (i.e. three months).

“High-level” meant that we had a list of features, bugs, and requirements, not fully estimated but well-understood by the team. In practical terms, we had high-level descriptions of the user stories, bugs, features with acceptance criteria and testing plans. There is some degree of variability; however, we had to consider that stories weren't estimated so they may overrun our timeline. So, as we went through the estimation process, sometimes we would be required to simplify user stories to accommodate them within our fixed schedule of 2 sprints (or communicate that it would take longer than initially expected).

In our “Flexible” stage, between 7-12 sprints, we operate on themes.

“Themes” were defined as an overview of the epics that we would like to focus on next, without breakdown or estimate. These themes described our main area of focus, without narrowing the strategy down to this specific area. Sometimes agile may feel a bit tactical because we are focusing on very granular work items so themes helped us track our strategic goals. ?Also, this area is where I expected our team to pivot to meet new customer requirements!

In our “Fuzzy” stage, beyond 12 sprints, we had a fuzzy roadmap

“Fuzzy” meant that we have themes that align with our product vision but these are open to challenge!

This approach helped us quite a lot in managing customers’ expectations. It also became easy to communicate changes to the roadmap because users now understood how the roadmap was prioritised and which areas they could use to plan their work. End of the day, we were trying to increase our customers’ confidence that they will get enhancements within a specific timeline. Getting the former right helped with our retention! Happy customers, Happy Product Manager ??