Agile Roadmapping: Our Software Development Strategy to Deliver Top Quality

"Responding to change over following a plan" is an important axiom of the Agile development philosophy. But that doesn’t mean there’s no planning.

Plans or response to changes? Long-term strategy or tactical goals? Predictability or adaptability? Both components are important to us. And one doesn’t work without the other. In this post we’ll reveal how we manage to reconcile these opposing points with the Agile Roadmapping.

Roadmapping as a Process

In essence, the word "roadmap" is not quite a true metaphor. On a roadmap, all the details are drawn with the same level of detail, no matter how far away they are. This is not what we want when it comes to the process of building product development plans. We don’t want to waste time on details that are likely to change - not until we get to them. We want to clarify things as the horizon of our understanding broadens.

Therefore, from here onwards, we will use the word "roadmapping" to emphasise that this is not an artifact but a collection of processes clarifying goals, milestones, metrics and other important details of product development.

Is Roadmapping the Development of a Product Backlog?

The product backlog is a list of requirements for software functionality, ranked in order of importance and edited by all participants in the process. The development of a product backlog is a useful exercise in the joint study of details. As we’re an experienced Scrum team, we’ve learned to conduct it regularly. This is also a good chance to look behind the veil of the current sprint, to look a little ahead, to understand the details of the forthcoming work.

The collaboration between the product owner and the development team in Scrum helps us have enough future details to predict the release dates of certain features and plan architectural improvements without doubling our workload.

The backlog is usually limited to a few sprints forward - from a couple of weeks to a month and a half - and we try to conduct them "on-the-go", often as a one- or two-hour meeting per week. So, as our experience shows, such meetings are not enough to see the overall big picture. Questions are accumulated, the vision fades and the fragmentation of knowledge intensifies.

When there is no general picture, you will never have enough details. A backlog without roadmapping, therefore, is not very effective. Grooming, conducted after roadmapping, reinforces a common understanding - from the greater to the lesser, from the general to the particular.

Roadmapping Goals

The goal of the roadmapping process is to gather together disparate fragments of the overall picture. This includes four vectors:

• Understanding the current state of the product;
• Defining business strategy and goals;
• Investigating the market and user needs;
• Highlighting technical limitations and risks.

The format of the roadmapping session is essentially reduced to bringing together these four vectors. How? It's very simple: give the opportunity to those with information about any given one of them to share with other team members.

Benefits of product roadmapping:

• More Alignment: all participants in the product development process - stakeholders, business representatives, management and engineers - get the overall picture. This creates consistency at the level of strategy and long- and medium-term goals and ensures that everyone goes one way.
• Less Management: the availability at the strategy and planning level reduces the need for management (and in particular documentation). When the goals are agreed upon and understood by everyone involved, much less detail is needed in order to ensure a common understanding.
• More Self-Organisation: understandable goals (and their approval by all participants in the process) allow development teams and their participants to make daily decisions and freely experiment without waiting for "approvals" from above.
• Better Products: and this, of course, is our goal! But it is achievable only indirectly ... We believe that regular sessions of joint updating and roadmap-building allow for the making of making better products.

Check out the whole development process here.

Read more about our development practices:

Agile software development

Scrum in software development

MVP development and bespoke solutions for startups

And we are always glad to see you in our London office for a cup of tea or just to have a chat about your project.

Alexander Bessudnov

Chief Product Officer

With a passion for innovation and a keen understanding of market trends, Alexander plays a pivotal role in shaping Magora's product development strategy and ensuring the delivery of cutting-edge solutions to clients.