Being agile doesn’t mean not knowing where we are going. It means being flexible about the path we take. Agile approaches promote transparency, and product roadmaps help make that transparency tangible. As projects become more complex and involve dozens or even hundreds of people, as in scaled agile environments, it becomes crucial to keep everyone aligned. In this context, long-term planning is hard to avoid. 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 is an Agile Roadmap?
A roadmap is both a product vision and a plan.
A roadmap is a high-level, strategic plan that outlines the expected evolution of a product over time. Product owners and product managers use roadmaps to show future functionality and when new features may be delivered. A roadmap is a practical tool for the team’s everyday work, as it outlines where the product intends to go. In agile environments (and even in every product development), it is especially useful for sharing a common product vision.
Once a roadmap is up, it’s good 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 should 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. Can a roadmap that looks almost like a Gantt chart 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, and so will your roadmap. An agile roadmap can take the form of:
- Theme or Epics-based roadmap: this is valuable to view the big work spans over several iterations. In Tuleap, if you want to go deeper in a single epic, you can drill down to see its child features.
- Milestones roadmap: create your product roadmap by iterations or sprints, without necessarily linking those sprints to specific dates.
- Hybrid roadmap: if your project still includes 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 PowerPoint documents. They can do better; they can improve the way they build and share strategic roadmaps. They can create product roadmaps very close to real life, where the development happens.
Tuleap Roadmap is set up and displayed in the team workspace itself, not in a third spreadsheet. This improves alignment and keeps the roadmap connected to real project data.
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 and cannot be displayed on a personal dashboard.
From an agile perspective, no additional effort is required from the team. Neither in terms of configuration, nor in terms of practices for the team. It’s 100% transparent for the team whether there is a Gantt on top of their work or not. And that’s actually a rather good sign that we don’t compromise agile values here. 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 a “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 an end date,
- or a start date and a duration (in days).
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’s 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 are 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 are 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:
As usual in Tuleap, configuration is under project administrators’ control. They can give any kind of context with the configuration panel:
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. It’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 where 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.
With the proposed organization, we have an actual ongoing 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 into Q1 2022 and Q2 2022).
On Tuleap Roadmap, the red ribbon will reflect those changes:
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 many of them.
But the good news is that typical Agile breakdown already solves this problem with “Epics” (or Themes, Features, etc.). Epics are coarse-grain splits 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:
In terms 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 the magic happen:
