Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Create Beautiful Roadmaps in Minutes - NOT!

DZone's Guide to

Create Beautiful Roadmaps in Minutes - NOT!

Does your Agile team create roadmaps prior to a Sprint to help guide your process? If so, read on for some pitfalls in this practice to avoid.

· Agile Zone
Free Resource

See how three solutions work together to help your teams have the tools they need to deliver quality software quickly. Brought to you in partnership with CA Technologies

Subject: Create Beautiful Roadmaps in Minutes

Body:

Hi << Test Name >>,

I hope you enjoyed reading our guide to product roadmaps.

If you haven't already built a roadmap in _____, I'd encourage you sign up for a free trial.

Why did this email annoy me so? - apart from the failed name substitution that is.

This e-mail, perhaps spam or perhaps something I did sign up to, landed in my e-mail box the other day and set my blood boiling.

Roadmaps should most definitely NOT be created in minutes. A roadmap should take time, in fact, roadmaps should take lots of people’s time.

  • Roadmaps should NOT be a list of features with dates.
  • Roadmaps are NOT promises.
  • Roadmaps based on work effort estimates will undoubtedly fail.
  • Roadmaps describe what MIGHT happen in the future to your product(s) and company.
  • Roadmaps should be informed by known events (upcoming shows, purchase needs of potential customers, legislation changes, etc.).
  • Roadmaps should consider how technology changes might play out.
  • Roadmaps should consider how your technology can help your (potential) customers with the problems they will have tomorrow.
  • Roadmaps should be informed by company strategy and roadmaps will feedback to company strategy.
  • Roadmaps should be flexible because the future will be different than any predictions you make.

The value of roadmaps is not in what they say. There is a lot of value in what they don’t say - the things that the organization will not do. But the real value of the roadmap is in the creation of the roadmaps.

The act of creating the roadmap brings key people together and exposes them to information about the future.

Peter Drucker once said: “We have no facts about the future.” But there are probabilities: population change is one that can be accurately predicted years ahead (e.g. we know how many 20-year-olds there will be in 10 years time). Most legal changes can be seen coming at least a few months out. There are things we can take a view on, there are things we know we don’t know, and things were we need to keep options open.

When key people are brought together they can exchange information and views. They can share their views of the future, they can talk about how they see the future, they can build a shared model and out of these can come a possible future, a possible scenario, a roadmap, which shows how your product will add value to some customers.

Because that’s what a roadmap is: a scenario plan, one or more possible descriptions of the future for your product.

Like so much planning it is the exercise of creating the plan that is the valuable bit rather than the resulting plan itself. This is especially true for roadmaps which are attempting to look far into the future. Roadmaps need to be a mix of prediction and opinion.

Roadmaps should bring people together for a discussion, to hear each other's voices and opinions; creating the roadmap should be a discussion.

Reducing roadmaps to a few minutes work with a tool destroys the value of the exercise. Any organization that does this has a pretty screwed up idea of collaboration.

Next time you need to create a roadmap:

  • Gather relevant information about the future.
  • Look at company cycles, look at competitor and customer cycles, and ask yourself,  what can we see?
  • Look at technology trends.
  • Bring together a mixed group of people: senior executives, technologists, salespeople, and product managers.
  • Spend time building your view of the world.
  • Consider how your product can help that world and help your customers solve the problems they will have.

And repeat the process regularly, say every six months.

You might even build several scenarios about the future and consider the implications for your product in each. Such scenario roadmaps are there to shape people's view of the future. Your scenarios will probably be wrong and the roadmap will play out differently in the end but allowing people to consider alternative futures challenges them to think differently. When real events happen the fact that people have considered alternatives will mean they are better prepared - even though the future will be different to all your scenarios!

Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies

Topics:
agile ,sprint planning ,scrum teams ,feature mapping

Published at DZone with permission of Allan Kelly, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}