Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Principles of an Agile Roadmap

Blog - Principles of an Agile Roadmap - Illutsration1.018.jpeg


Sally, the Technical Lead at Software Company ABC wants to know why her Product Manager insists on using a product roadmap;

"We're an agile team right? It seems un-agile to set concrete dates in an out-dated document for stuff that we should (but probably won't) get done."

Ahhhhhh, yes. A common question in agile software development. 

To first understand why every agile software development team needs a product roadmap (and yes, you all need one), we must first pull apart Sally's question and see why she asked the question in the first place. 


"We're an agile team right?"


Now there are a few things to note here. 

The first is Sally's assumption that a product roadmap is not an agile tool, rather an exhausted practice dragged across from Waterfall predecessors (*cough* Gantt Chart *cough*). 

It's a common misconception, and something that we've covered before in this blog post, but no, roadmaps are not the same as Gantt charts. 

In short, Gantt charts assume that work will be completed in a linear fashion and are for task dependency and critical path management. Michael Dubakov contextualises it perfectly when he said;

"Agile is not about task dependency and critical path management - it's about  | flexibility and temporary dependency."

Enough about Gantt charts, let's get back to Sally's question. 

"It seems un-agile to set concrete dates on an out-dated document for stuff that we should (but probably won't) get done."

I agree with Sally on this one. It is un-agile to set concrete dates on a document that is not kept up to date. 

Here lies the problem. Sally is under the impression that the product roadmap is a time-bound, fixed promise for deliverables. 

Now we know that if the environment you are operating in is agile, change is inevitable. Customer needs an requirements change on an ongoing basis, and your roadmap should reflect how you intend to provide value to your customers. This means your roadmap should be regularly reviewed and adjusted to accurately reflect that. 

Product Manager's need to educate their stakeholders that the product roadmap is not a promise. It is a living-document meant to serve as a guide and is subject to change. The roadmap represents the activities a team is looking to deliver on, based on providing the most value to their customers in that snapshot of time. We just discussed that these needs are almost always going to change through time, and the roadmap should be updated to reflect this. 

This means communication between all stakeholders is extremely important. So how do we ensure that communicating these changes in deliverables is streamlined across all stakeholders? A product roadmap - who would have thought!


Guiding Principles to ensure your agile team gets the most out of your product roadmap


1. Focus on Themes of Work not Features 

In their simplest form, themes represent high-level groups of work (like epics). In an agile product roadmap, these themes should be customer-focused unlike traditional waterfall roadmaps where themes tend to be focused on business objectives. 

Examples of themes include;

  • Customer On-Boarding Experience 
  • Reducing Tech Debt 
  • Customer Satisfaction and Engagement 

By grouping work into themes, teams are able to tell a story about where they are headed and the goals, objectives and outcomes that will get them there. This high level visualisation allows team to easily answer the following questions:

  • What are we doing?
  • Why are we doing it?
  • How does this link back to our OKRs?


2. Think of the Roadmap as a 'Living Document'

As I mentioned before, Product Manager's need to educate their stakeholders that the product roadmap is not a promise. It is a living-document meant to serve as a guide and is subject to change. 

It is important to educate all stakeholders that the roadmap represents chunks of work valued most by customers over a certain period of time. It is inevitable that those customer preferences will change over time, and the roadmap should be altered/amended to reflect that. 


3. Actively Collaborate with Stakeholders when Setting/Reviewing the Roadmap

It is unrealistic to think that as the Product Manager, only you can represent the customer voice. 

By engaging the perspectives of developers, sales reps, customer support and engineers in the process, a holistic view of the customer experience is understood, thus a more realistic basis for determining what we should do and when, because we know out customers value this. 


4. The Roadmap Needs to be Somewhere Accessible to all Stakeholders

The Product Roadmap should be the team's single source of truth, representing the plan of execution against the companies OKRs.

Visibility into 'what's going on' and more importantly 'why am I doing what I'm doing?' is crucial in establishing transparency and confidence in your team. 

The roadmap represents the overall vision for the team for a period of time, and ensuring the roadmap is accessible to all stakeholders is a way of achieving organisational alignment. 



Log in or Sign up to comment
AUG Leaders

Atlassian Community Events