Being agile doesn’t mean not knowing where we are going. It means being flexible about the path we take. Agile approaches promote more transparency, product roadmaps create transparency. When projects become more complex, onboard dozens and even hundreds of people as in scaled agile, it’s crucial to keep everyone in sync and it’s difficult to escape long-term planning. Tuleap provides a way to share the vision of the whole project over time. Let’s see how to build an agile roadmap in Tuleap (demo video at the end of the article).

What’s an Agile Roadmap?

A roadmap is a product vision and plan

A roadmap is a high-level, strategic plan, that shows the likely development of the product over the time.  Product owners and product managers use roadmaps to show future functionality and when new features will be delivered. A roadmap is a real tool for the team’s everyday work, as it outline where the product intends to go. In agile environments (and even in every product development), that’s really useful to share the product vision.
Once a roadmap is up, it goods to share it with the entire product team so everyone understands the direction and the vision . We regularly see it in methods for agile at scale, notably in the SAFe framework, as multiple agile teams like sharing a single product roadmap.

Product roadmaps in the agile world

First and foremost in the agile world, a product roadmap is a statement of intent. It can not be a frozen roadmap. It can’t be the addition of hard deadlines that must be met. Rather, it should be an incremental plan that openly embraces change. Because, is a roadmap, that looks almost like a Gantt chart, can be agile? Read our CTO Manuel’s article about how to use a Gantt Chart in Agile Project Management. Because, yes, plans can and will change, so will your roadmap. A agile roadmap can take the form of:

  • Theme or Epics-Based roadmap: this is valuable to view the big work spans on several iterations. In Tuleap, if you want to go deeper in a single epic, you can drill down to see it’s child features.
  • Milestones roadmap : create your product roadmap by iterations or sprints, without necessary linking those sprints to specific dates
  • Mixed methods roadmap: if your projet still include waterfall elements, your product roadmap can have dates as weeks.

Improving roadmap transparency

It is not rare to still see product owners creating their roadmaps in terrifying excel or power point documents. They can do better; they can improve the way they build and share strategic roadmap. They can create product roadmap very close to the real life, where the development happen.
Tuleap Roadmap is set up and displayed in the team worksplace itself. Not in a third spreadsheet. This promotes empowerment of those involved and the chart is more connected to the reality on the ground.

Tools to be used in Tuleap to create a roadmap

To create a roadmap in Tuleap, you will need 2 things:

  • the “Agile Dashboard” plugin activated in your project and configured for Scrum,
  • a “Roadmap” widget.

Note: in Tuleap, a roadmap is a widget displayed on a project dashboard et cannot be displayed on a personal dashboard.

On the agile side, there is nothing to do at all. Neither in term of configuration, nor in term of practices for the team. It’s 100% transparent for the team whether there is a Gantt top of their work or not. And that’s actually a rather good sign that we don’t compromise the agile values there. The magic sauce is done with a bit of configuration of Tuleap Trackers and more precisely the definition of Tracker semantics.

Configure your product roadmap

Tuleap Tracker’s magic sauce: semantics

You can skip this paragraph if you speak Tuleap configuration fluently.

Tuleap Trackers are a generic structure, it’s not an “bug tracker” or a “user story tracker”, it’s a data structure designed to track all types of tickets, issues, tasks, etc. (read this additional article about Tuleap Tracker concepts).
Sometimes, Tuleap needs to identify some key aspects of this data structure. If there are 3 string fields in a “bug tracker”, how do I know which one represents the summary of my bug? It’s the role of “Title Semantic”. Tracker administrators can define which field is “Title”, which field is “Description” and so on.

To render the bar on the roadmap chart, the tracker administrator is going to define:

  • Timeframe semantic
  • Progress semantic

Roadmap Timeframe

Timeframe semantic exists since a while and already allows to define a time period with:

  • either a start-date and a end-date,
  • or with a start-date and a duration (in days).

From Tuleap 12.10, timeframe evolves to allow a third definition: inherited timeframe.
Instead of having a date on itself, the artifact is going to inherit it from another artifact. Sounds too abstract? Let’s take an example:

Let say “User Story tracker” inherits Timeframe from “Sprint tracker”. Then we have a user story written as: “At first login, user should see an alpaca gif”. This story is linked to the sprint “Sprint 12” that starts on Monday 21st of June and lasts 10 days. Then the timeframe of the story “At first login, user should see an alpaca gif” will be from Monday 21st June to Friday 2nd of July.

Roadmap Progress

Progress semantic is the newest of all semantics. When defined, Tuleap will compute the percentage of completion of artifacts. There are two ways at the moment:

  • either relation between a remaining effort and a total effort,
  • or by counting linked artifacts: the number of closed artifacts versus the total number of them.

Milestones in the ribbon

There is more conceptual differences between Agile approaches and what is expected to be rendered on a Gantt chart. Milestones, for instance. On a waterfall Gantt chart, a milestone is literally what you find on the shoulder of the road: a landmark, a single point, the point to reach. Either you reach it and it’s a success, or you don’t and it’s a failure. On the contrary, Agile approach is more a continuum. There is way more “milestones” (releases, iterations, etc) and it’s more about the period of time.

With the Tuleap Roadmap widget, this contextual information can be displayed at the top, in the time ribbon:

agile roadmap timeline
Roadmap timeline ribbon with project’s Releases and Sprints

As usual in Tuleap, configuration is under project administrators’ control. They can give any kind of context with the configuration panel:

Rodmap widget configuration

Long-term roadmap

Gantt charts can be used to present a Roadmap with long term view. This can be seen as diverging from Agile mindset but there is still a strong attraction for mid/longer term. That’s true Agile teams value the ability to react to changes over plans (it might remind you something). Even if everybody knows that it’s not what will happen, it’s a way to share the information “we are heading toward this direction“. According to the agile framework SAFe “The Roadmap is a schedule of events and milestones that communicate planned solution deliverables over a planning horizon.”

It’s also possible to build long-term roadmaps in Tuleap. To be fair it’s still a bit hack-ish but it shows were we are heading 😉

Shape the future with releases and “pseudo releases”

In your Tuleap Agile Dashboard, you are going to create “pseudo milestones” that will represent the future. It’s quite common to communicate roadmaps based on quarters or semesters.

“Pseudo milestones” to prepare the roadmap

With the proposed organization, we have an actual on-going release, “Release 4.0-Summer”, while “2021 Q3, Q4”, etc are “pseudo releases”. Those “pseudo releases” will always be there, always “planned” but their names and dates will change. For instance, as soon as the releases for the third quarter of 2021 are planned with their actual contents (Release 5.0 and 6.0), the pseudo releases will shift toward 2022 (S1 2022 was split in Q1 2022 and Q2 2022).

Summer releases are real, the “pseudo releases” will shift to 2022 if necessary

On Tuleap Roadmap, the red ribbon will reflect those changes:

“Pseudo releases” on the Roadmap

Content for “pseudo releases”

So we can create “pseudo releases” to materialize the future ; but what about what’s in those releases? Most of the time, in the actual releases, we plan user stories. Those stories are well defined with acceptance criteria. It’s a good practice to have stories of roughly the same complexity. But that doesn’t fit in the quarter/semester pseudo releases. It would mean that in our backlog, we would have real and fake stories. And while it’s a solution for “pseudo releases”, it cannot be done with “pseudo stories” because there would be too much of them.

But the good news is that typical Agile break down, already solves this problem with “Epics” (or Themes, Features, etc). Epics are coarse grain split of a domain but not detailed enough to be a user story. As you probably already figured out, while actual releases will continue to be filled with user stories, we are going to leverage epics in “pseudo releases” to shape the Roadmap.

As we don’t want to pollute the backlog view with epics, we are going to link them at artifact level:

Epics are linked to pseudo releases at artifact level

In term of configuration, Epics are going to inherit their timeframe from Releases. And the Roadmap widget will be configured to display both epics and user stories. And then, let’s the magic happen:

Roadmap with what’s going on and what’s planned without too much hassle


🔥 Roadmap got its load of changes to match how we originally intended to deliver the feature: the ability to automatically draw a Gantt chart on top of the Agile Dashboard without any compromise on Agile values.

Wanna learn more about Agile tips and tools?