Like other roadmaps, an agile roadmap is a plan for the future. That may be for the next release or the next 5 years of the product. Agile roadmaps focus specifically on functionality or features to be released in a product in the future, and not the work that accomplishes those things.
Benefits of Agile Roadmaps
Agile roadmaps can provide alignment to teams by facilitating a common vision and understanding of the product and it’s future. Agile at it’s core is a framework for building products, and agile roadmaps help with that process.
They can be used by the entire company to facilitate conversations around product releases, specific features and everyday work.
Agile roadmaps can also be shared across multiple agile teams, so there is a better understanding of what each other is working on. This gets teams talking that otherwise might be siloed (and not talking). An example of this could be marketing and your support team, or development and sales. You may not think this is an issue, but maybe you haven’t been working for a large corporation where this is sometimes the status quo.
Agile roadmaps should remain at a high level. They should really represent a strategy of product development going forward. They provide a visual to accompany a product manager or product owner’s story or vision of the product going forward.
In Roman Pichler’s article, 10 Tips for Creating an Agile Roadmap, he states
“Your product roadmap should tell a coherent story about the likely growth of your product.“
Avoid details in your map – they don’t belong there (and there are better places you can put them). Details are low-level information that will take away from the high-level nature of your roadmap. People may begin focusing more on the little things instead of the big picture if you put them in.
Details should be kept in other documents such as specifications, stories or epics, but not on a roadmap.
Keeping focused on the high level helps stakeholders stay focused on the intention of the roadmap, and not get get caught up in the weeds.
Go easy on the dates
Dates are a controversial in roadmaps.
Some strongly object to them because they feel that dates are promises made, and you know how the old saying goes – promises made are promises kept. So when you can’t keep to the process you originally promised, stakeholders may look down upon that.
Others argue that dates are needed in order to give the roadmap context and an idea of the type of timeline you are talking about.
I fall somewhere in the middle. I believe that too many dates can be detrimental to your document, and will ultimately lead to failure to meet commit dates at some point. Some context as to how long teams will be working on certain features can be helpful for teams to understand the business’s larger vision.
All together now
At a minimum, all team leaders who are involved with execution of the work should have the ability to provide input or impact the rows or “swimlanes” of the map. Building a roadmap is a team building excercise – make it fun and collaborative.
Is it a roadmap or release plan
An agile roadmap captures high level features, initiatives and goals – a vision for your project. As outlined above, it should not go into details of the product or execution.
A release plan on the other hand, is a commitment to plan to deliver a increment of product value, as defined by CA Technologies here. Release plans can be executed in much shorter increments, and are intended to reflect the work to be done during a release period – not so much what the goals or vision for product improvement are.
Agile roadmaps can be an excellent tool to share a common business and product vision across functional teams.
If your looking for more specifics about product roadmaps, check out a great comprehensive article on the topic by This is Project Management.
Have you had any successes or failures with agile roadmaps? Did we leave anything off? Let us know below!