From requirements to roadmap

Following the process explained in our post Keeping Track of Requirements with Light-weight Tools will yield us a set of requirements. How can we turn these into a reliable roadmap for the future evolution of an application, team or project?

What is our goal?

According to Atlassian:

A product roadmap is a shared source of truth that outlines the vision, direction, priorities, and progress of a product over time. It’s a plan of action that aligns the organization around short and long-term goals for the product or project and how these goals will be achieved

Requirements are the result of a clinical analysis of the goals of a software system or software portfolio and the expectations of its stakeholders. A roadmap describes how the goals can be achieved in a given technical and business environment.

Conflicting points need to be carefully considered when making the journey from a set of requirements to a roadmap. Projects usually consist of a mixture of greenfield development, maintenance, and code rejuvenation. The business case can often be made for greenfield development and the necessary funding obtained. This is much harder for maintenance and rejuvenation since their progress and business value are harder to prove. A further complication is that mixing maintenance and rejuvenation is usually ill-advised from a technical perspective. The roadmap should propose staging and dependencies between subprojects that reconcile this.

Organizations differ in how quickly they can absorb innovation. This depends on available human resources, available expertise, and organizational policies. The roadmap should reflect these aspects as well.

Preparations

During the preparation of the requirements, we identify logical dependencies between parts of the desired software system. These dependencies dictate a temporal ordering of these parts. However, there are technical considerations that also influence this ordering. The combination of logical and technical dependencies is crucial when formulating a realistic roadmap. Some questions to ask are:

• What are the technical needs and dependencies for each component?
• What are the business needs regarding the business value, training, and use of each component that affect ordering?
• Which ordering leads to the best spread of maintenance and rejuvenation activities that do not conflict with greenfield development?
• Which ordering leads to early proofs of concept?
• Which ordering is compatible with available resources?

Outline of a roadmap

Our roadmaps try to reconcile all constraints while taking the aforementioned considerations into account.

A roadmap defines top-level tracks. A track is a coherent set of activities, which are usually related to achieving one high-level goal and depend on each other.

Each track is subdivided into projects. The ordering of projects is dictated by technology and business. Each project aims for early proof of concepts that show their business value to stakeholders as soon as possible.

Planning and time estimates depend on:

• the actual work: design, implementation, testing, integration;
• the available personnel and expertise to carry this out;
• the absorption capacity of the host organization.

At any given moment, projects are active in each of the categories: greenfield, maintenance, and rejuvenation. This ensures that essential maintenance and removal of technical debt make progress without disturbing other activities.

Formulate the roadmap

Once these preparations have been made, we can formulate the roadmap in a few steps:

1. In a spreadsheet:
   1. define top-level tracks (main focus points of the project);
   2. identify projects – aim for projects that have a beginning and an end (every project has a name and is linked to one or more tracks);
   3. map projects to solution requirements (obtained using Keeping Track of Requirements with Light-weight Tools) in a big matrix.
2. Ensure every project is linked to at least one solution requirement.
3. Define per project what its predecessors are. This defines a dependency graph.
4. Generate an interactive HTML document (with a PDF export) to browse the tracks and projects with links back to requirements related to each project (and summarize at the track level).
5. Visualize the dependency graph.
6. Write a manual report explaining the best scheduling of the projects, and where possible, summarize the project dependencies and scheduling in a visualization that captures the complete roadmap.

The example below shows a spreadsheet that links the previous requirements to a roadmap:

📖 Load embedded spreadsheet (accepting Google Docs cookies) 🔗 Open spreadsheet in Google Docs

This spreadsheet can then be used to generate the following appendix for the roadmap document:

Key takeaways

• Multi-year roadmaps created in this way are reliable and effective.
• Where necessary, they can be adapted and recreated in an agile fashion.
• Most important of all, these roadmaps act as a shared source of truth that determines and motivates the direction of all participants.

Get in touch

Do you face challenges in requirements engineering and roadmapping? Then reach out to us. We will be happy to discuss how potential applications of our expertise could solve your IT challenges.

Header image from ScrumAlliance