Create and Maintain Product Roadmaps using Agile Principles

delivery of priority business values. So business analysts became these key resources who could move with equal ease between the development teams and the product management team.

Challenge: Stakeholders, in traditional mode, will be involved only once or twice to define product roadmaps. In this agile roadmapping process, on the other hand, it is expected that the roadmap will continuously evolve and change based on feedback from agile teams and on changes in market realities. The product roadmap becomes a ‘live’ artifact to which the stakeholders were held accountable along with the product manager.

Solution adopted: Weekly meetings were introduced to discuss and dissect the product roadmap and reprioritize the backlog based on inputs from different departments within the organization. This top-down input to the product roadmap process increased the overall trust and accountability of the stakeholders. Few or all of these meetings happened within the scope of the sprint activities depending on the duration of the sprint and current sprint backlog. Soon, we adopted a two-week sprint schedule to accommodate the product roadmap prioritizations into the sprint backlog.

Challenge: Agile project teams - used to working in daily, sprint, and release modes - usually have low visibility into the product roadmap and hence corporate strategy. With Agile roadmapping they are involved in early estimation and release planning which affect the overall velocity of delivery.

Solution adopted: We successfully introduced this phased approach so that the team could get involved in the roadmapping process without significant delivery impact. Introduction of dedicated business analysts also enabled the project team to understand not only project backlog, sprint backlogs and release plans, but also business plans that provided overview of product vision, goals and how they fit into the overall corporate strategy, and the product roadmap. This new insight increased the confidence of the team as they were now sure that in every sprint their effort was directed towards building the prioritized product roadmap to deliver the most optimum business value.

Conclusion
We experimented with this approach by moving over to two week sprints (instead of the usual one week sprint cycles) and involving the business analysts more closely in the roadmapping 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.

About the Authors

Anupam Kundu is a Certified Scrum Master and Lead Consultant with ThoughtWorks Inc, a global IT services firm focused on end-to-end software delivery. He has more than 10 years of experience in various stages of software development life-cycle and post-implementation activities and is focused on enabling multiple teams through active adoption of Agile practices in the field of global outsourcing services and global software delivery models with distributed teams. Anupam lives in