Project Management Basics – Chapter 16 – Agile – Product Roadmap
“Always plan ahead. It wasn’t raining when Noah built the ark.” Richard Cushing
“A good plan is like a road map: it shows the final destination and usually the best way to get there.” H. Stanley Judd
The product roadmap is a recurring source of confusion for students aspiring to the Project Management Institute Project Management Professional (PMP®) certification. I believe it is because we describe the roadmap as a document that describes the vision and strategy, helps align stakeholders, provides guidance as we execute against the strategy, and is an effective information radiator.
Then we say it is neither a schedule nor a promise of functionality.
While those seem to be conflicting ideas, they are not.
It begins with the Benefits Management Plan. A more detailed description of that plan can be found here: https://www.projectmanagementforum.net/post/project-management-basics-chapter-4-product-metrics
The Benefits Management Plan describes how and when business benefits are to be realized and assisted us in deciding that an agile approach was needed. The Benefits Management Plan also serves as the basis of the product roadmap. We develop the product roadmap by logically grouping together features that will be delivered as functioning software, meaning it can be deployed into a production environment. Most organizations refer to that as a minimally viable product.
Once we have completed the logical grouping, we estimate how long it will take to develop each group of features. With that done, we have completed our product roadmap!
With the roadmap completed, the next step is to determine our first product backlog. The development team works with the product owner to identify and refine the user stories (agile requirements) that will comprise the product backlog. The level of effort to deliver the first release is now understood, so the product owner and development team can determine the number of sprints required to deliver the product backlog. Adjustments are made to the product roadmap based on this new understanding of the nature of the work and the level of effort.
The reason the product roadmap is not a firm commitment to deliver certain functionality by a certain date is because of the iterative nature of agile development. We may decide that certain features can be pulled forward into the current development cycle, or we may decide it makes sense to defer certain functionality into later releases. Once the teams productivity (velocity in agile terms) is known, we can further refine the timing of the releases.
The product roadmap is an important agile artifact, but it is not a promise!
Next I’ll discuss the Minimally Viable Product and the Minimum Business Increment.
Coda
I am thinking of doing a series on financial literacy. With my daughters either leaving for college or moving out to begin their separate lives, I am having a lot of financial discussion with them. Interestingly, they have begun to direct their friends to me with financial questions. I was watching one of the “Wives of” reality TV shows with my wife, and even at that income level their knowledge of finances was shockingly low. Let me know your thoughts.
#project #program #agile #leadership #projectmanagement