"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
Roadmapping as a Process
In essence, the word "roadmap" is not quite a true metaphor. On a
Therefore, from here onwards, we will use the word "
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
The goal of the
- Understanding the current state of the product;
businessstrategy and goals;
- Investigating the market and user needs;
- Highlighting technical limitations and risks.
The format of the
Benefits of product
- More Alignment: all participants in the product development process - stakeholders, business representatives, management
andengineers - 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:
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.