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:
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:
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 ??
HSEQ
2 年Great way to bridge the information between the technical side and the clients side while managing client's expectations.
Solution Owner - Biodiversity Monitoring for Offshore Wind Sites Opinions shared are my own and do not necessarily reflect those of my employer.
2 年Great idea! I think this would be useful for conversation with any non-development stakeholder, not just customers. I will experiment with this. Thank you for sharing.
Isn't this just a different way of describing a typical Scrum backlog? I.e. defer refining stories in a high level of detail until necessary and/or committed by the team?
Consultant, Systems Insights & Solutions - at PA Consulting
2 年Great article Victor Borges. I think the term fuzzy is perfect to describe those features far out into the future!