Product Roadmaps
From AgileBok.org
A common question that come up when discussing Agile/Scrum is how to develop and maintain a product roadmap in an Agile environment. The confusion seems to come from the focus of Scrum on short development cycles and the ongoing prioritization and re-prioritization of needed functionality in the Product Backlog.
Contents |
What is a Product Roadmap
A roadmap is a planned future, laid out in broad strokes — i.e. planned or proposed product releases, listing high level functionality or release themes, laid out in rough timeframes — usually the target calendar or fiscal quarter — for a period usually extending for 2 or 3 significant feature releases into the future.
For startups or companies in fast moving and growing markets, those 2-3 releases might only cover the next 12 months of time. For other more mature companies in less dynamic markets, those releases might cover several years.
We emphasized the word “planned” above. Plans are simply plans. They are our intentions for the future given what we know and believe today. They are not commitments. Most roadmap presentations I’ve seen, and virtually every single one I’ve seen from a public company starts with a big disclaimer that absolves the company from committing to anything that is presented in the roadmap.
Product Roadmap in Agile Development
A key question that often arises when discussing agile is how to develop and maintain a product roadmap in an Agile environment, since both do not seem to co-exist very well together. The constant focus of Agile methodologies on shorter development cycles and repeated prioritization of functionality in the product backlog clashes with a long term product map. Though Agile does not dwell on the Waterfall approach of defining system requirements for months and years to have the development started, it is always mandatory to be well planned and have a clear path ahead for any development effort to succeed.
Hence having a product roadmap even when following an Agile approach is a must. A product roadmap is a planned approach that helps with strategic project planning and communication of that plan with respect to product releases, functionality listing etc. But it should be formulated by first understanding the target users, the market, and the underlying technologies. Product roadmap forms an integral part of any product strategy and provide the framework for plan changes and the impact they would have on the product. It’s not just about the specific features or functionality of the product, but the long term product vision/goal of how far one would go with it.
The general perception today is that in Agile, unlike the waterfall model, it is difficult to chart out and manage an effective long –term product roadmap. However, Agile reflects the reality better because the planning is done only for the current items and the immediate iterations that may follow. And this necessarily avoids one from making a long-term product goal (say 6-10 months ahead), which may fail because priorities/requirements of the products often change. Moreover, making a long range roadmap has always been a real challenge in general.
In Agile, the roadmap and approximate dates are calculated based on the product backlog and the knowledge of the team velocity. Many a time over-commitment to the customers has been a major issue here. But product managers can certainly employ a centralized system that would ascertain development team velocity, all previously committed requests, and based on that, calculates the next available commit date for a task of importance. This always keeps one in check. A good agile product roadmap should invariably help one deliver the right products with the right features at the right time to the right customers.
Building a Product Roadmap
Building a product roadmap for the digital division of a large publishing firm is a strenuous process that is fraught with dangers. There are work items that need immediate attention, new marketing outreach initiatives, and then strategic projects to organize and develop the internal infrastructure. Correct prioritization of feature set, and planning a proper release that will address the executive strategy, are serious challenges for the product manager and the agile project teams.
Lack of fast feedback, inability to change course direction based on new priorities, and reluctance to gather inputs from multiple stakeholders can throw the team off track quite easily. To deal with this, the agile team introduced a tiered approach to develop and execute the roadmap. The tiered approach made sure that everyone’s voice was heard. To support this approach, the project moved from its initial one-week sprint to a two-week sprint to ensure the availability of sufficient lag to alter priorities for the teams without overburdening the release cycles.
Key points to consider while Building the Roadmap
At the client company, each product request in the roadmap was judged on multiple parameters to make sure that the roadmap consisted of feature sets that delivered maximum business value and remained aligned with the corporate strategy. A few of the key questions that were considered for building and prioritizing the roadmap are:
- What is the business value for the product?
- Is the new feature considered a legal obligation for the market?
- Does the new product provide a distinct competitive advantage in the marketplace?
- How much can the proposed product leverage the newly created infrastructure?
- Which product can help launch or promote new or emerging lines of business?
- Will the new product allow the stakeholders to reach and exploit new marketing geographies?
- How much will it cost to launch the new product?
- Is there a need to build follow-up modules to the product?
- Is this a new product a catch-up with rest of the players in the market?
- Is there a partner obligation for the product launch schedule?
- Are all necessary resources available for the product to be implemented?
- Which product addresses the most demanding stakeholder group in the company?
The idea was to initially create and maintain two backlogs for the product roadmap: one for all the bugs and enhancement requests; the second for all high business value products and new feature requests. Unless the bugs and enhancements were deemed to be critical, or if there was not enough work for the whole team, the sprint focus of the project team was always dedicated to new features and high value business products based on prioritization from the product manager.
The team adopted a quick feedback model to ensure that the project teams, distributed across the world, had visibility into the prioritized product roadmap, enabling them to them to stay focused on delivering the right projects. This provided the product owner and the stakeholders bandwidth to prioritize the project backlog based on the business realities of cost and implementation timeline.
Advantages of collaborative roadmapping
This feedback oriented, collaborative roadmapping process was a learning experience for all of us involved in the projects at the client company. We were quickly able to adapt the implementation direction based on learning from constant feedback sessions during roadmap meetings. All the team members felt empowered and considered themselves to be in the ‘thick of the mix’ rather than just doing vanilla implementation projects. Following are a number of the positive effects we witnessed.
Rapid portfolio management
Usually portfolio planning is a slow process as portfolio decisions are slower and more deliberate - involving a broad range of inputs from multiple stakeholders - and more impactful than product level decisions. However, agile product roadmaps are created and maintained iteratively with close collaboration between the stakeholders and project teams, hence portfolio planning progresses rapidly.
Ability to change roadmap direction
Agile portfolio management offers the flexibility to frequently update the roadmap based on close feedback and strong collaboration from the agile teams and the stakeholders. The product roadmap can undergo updates at any time during the release cycles; current project status, change in future financial projections, change in prioritization by the stakeholders, or a new legal requirement can be factored into the roadmap. Each of the phases provides enough information to the stakeholders to change their priorities based on reality checks.
Knowledge sharing
The goal of each of the phases overlaps with the next one; they are not water tight containers of activities guarded by gatekeepers, but rather collaborative, feedback-based time boxes geared to moving forward in the project selection process. At this client company, these logical phases not only provided our team with the perspective of the overall road map and the proverbial ‘big’ picture from a business value view point, they also enabled our understanding of the nature of the potential work, and the risks attached, during early analysis and estimation processes.
Conclusion
This approach has been experimented by moving over to two week sprints (instead of the usual one week sprint cycles) and involving the business analysts more closely in the road-mapping process. The business analysts enabled the product owners to significantly extend their bandwidth. We also modified the sprint planning meetings to accommodate discussion on the roadmap projects. These changes yielded positive results for our whole team and the stakeholders at the client company. As a whole, we saw marked improvement in productivity by adopting this phased model; the count of the number of new products released in a quarter went up, the highest priority products got quicker release timelines compared to the less important ones, and the team morale got a big boost. However, we recognize that this model is not a silver bullet for other projects or other business situations. It is important to remain aware that they are not guaranteed to give the same results every time for all teams. So product owners and project team members, feel free to adopt this model for your portfolio planning and then tweak it, if need be, as per the local sensitivities to achieve your goals.
