How to build, maintain and communicate the Product Roadmap?

One of the key responsibilities of a Product Owner is looking after the backlog and building and maintaining the Product Roadmap. The Roadmap is a great tool that provides a visibility regarding the Scrum team’s work and to materialize where the team is headed to. It’s a good practice to communicate the up-to-date Roadmap with the shareholders often in order to let them know which new features and bugfixes are planned over the coming weeks and months and to notify if there is a recent change on the planning.

We are running 2 weeks-long Sprints. At the end of the Sprint Review session, as the PO, I’m presenting the PBIs (Product Backlog Item) in priority order and ask openly to my line manager and other shareholders if we share the same understanding of priorities. From time to time chances are my management team and/or shareholders comment on the priority of PBIs and ask changes. On those instances, we altogether discuss about the motives of these new requests and get fully aligned. At the end of the review we as the team get either confirmation from the audiences regarding the priority order or have an updated list of priority. Here below you can see the ~3 months Product Roadmap of our team. (I’ve intentionally made it blurry for confidentially reasons)

It is quite likely that, some of the shareholders may not be present at the review meeting due to a certain number of reasons. That’s why, I may not be able to receive their feedback face-to-face on the Sprint Review session. To compensate such lack of communication channel, as a rule of thumb, I share the up-to-date Roadmap with my shareholders after a few days of the Sprint Review event. This allows my colleagues transparently know what we are actively working and let them come back to me if they have a comment to make.  Considering that we are running 2 weeks Sprints we don’t make plans for more than 3 months period. In most of the cases, we can only make high-level plannings for the 5-6 Sprints ahead of us. The remaining 2-3 Sprint scope is draft and requires to be refined.

As a final note,  we also rarely encounter cases where we need to make exceptional or unexpected modifications on the Roadmap. This might happen either by the sudden request of the top management or a immediate change request by the business teams due to the changes on the market regulation or competitive environment. If this happens, we are open to it and embrace the change as an agile team. What I’m doing as a general principle is, I’m trying to fix the scope of the next 1-2 Sprints while being flexible to play with the scope of the following Sprints.  I’m also asking my line management to support me on that as most probably we might have already put a pre-analysis/analysis effort for the near Sprints and we prefer to keep it. 

Schreiben Sie einen Kommentar