Communicating Agile Roadmaps
Image by: opensource.com

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

No alt text provided for this image

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!

No alt text provided for this image

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 ??

Great way to bridge the information between the technical side and the clients side while managing client's expectations.

Dan Smith

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?

Jack Rushforth

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!

要查看或添加评论,请登录

Victor Borges的更多文章

  • The Parallels of Product Management and Diplomacy: Communication and Conflict Resolution

    The Parallels of Product Management and Diplomacy: Communication and Conflict Resolution

    As a product manager, I've often found myself drawing parallels between my role and that of a diplomat. At first…

    12 条评论
  • Product Management and Cognitive Bias

    Product Management and Cognitive Bias

    In product management, understanding customers' needs and pain points is pivotal for success. However, unravelling…

    6 条评论
  • Roles in Agile Framework (Part II)

    Roles in Agile Framework (Part II)

    We will continue our discussion on roles and responsibilities by going through some really important roles - let’s…

    2 条评论
  • Roles in Agile Framework (Part I)

    Roles in Agile Framework (Part I)

    Agile methodologies have become increasingly popular in software development over the past few years, and for good…

  • As a deck builder, I would like to…

    As a deck builder, I would like to…

    As a deck builder, I would like to… I designed a deck! As surprising as this account may read, yes, I did! And I used…

    10 条评论
  • New ways of Managing Risk

    New ways of Managing Risk

    Data-Driven Decisions are at the centre of the next generation of risk management tools. Many industries have proved…

    7 条评论
  • Why Asset Performance and Risk Management?

    Why Asset Performance and Risk Management?

    The history of maintenance strategies helps to understand the new requirement for Asset Performance Management…

    3 条评论
  • Asset Performance (and Risk) Management

    Asset Performance (and Risk) Management

    Even a small improvement to the reliability, maintenance and operational efficiency can have a significant financial…

    6 条评论
  • NAIA: Passenger Journey Analytics

    NAIA: Passenger Journey Analytics

    The Benefits of Passenger Journey Analytics Due to the growth in urban population, there is an increasing demand for…

    3 条评论
  • Data Science in the Railway Industry

    Data Science in the Railway Industry

    Data science is a discipline that integrates data analytics, algorithm development, and technological processes to…

    4 条评论

社区洞察

其他会员也浏览了