The product roadmap is an overall view of the product's requirements and a valuable tool for planning and organizing the journey of product development. The product owner creates the product roadmap with help from the development team. The roadmap is used to categorize requirements, to prioritize them, and to determine a timetable for their release.
Keep in mind that you refine requirements and estimates throughout the project. In the product roadmap phase, it is okay for your requirements, estimates, and timeframes to be very high. Because priorities can change, expect to update your product roadmap throughout the project — at least twice a year.
Your product roadmap can be as simple as sticky notes arranged on a white board — which makes updates as easy as moving a sticky note from one section of the white board to another.
Step 1: Identifying your agile product requirements
When you first create your product roadmap, you likely will start with large, high-level requirements. The requirements on your product roadmap will most likely be at two different levels:
Themes are logical groups of features and requirements at their highest levels.
Features are parts of the product at a very high level. Features describe a new capability the customer will have once the feature is complete.
When you start creating requirements at the theme and feature level, it can help to write those requirements on index cards or big sticky notes. Using a physical card that you can move from one category to another and back again can make organizing and prioritizing those requirements very easy.
While you are creating the product roadmap, the features you identify start to make up your product backlog — the full list of what is in scope for a product, regardless of level of detail. When you have your first requirement, you have your product backlog started.
Step 2: Arranging agile product features
After you identify your product requirements features, you work with the development team to group the requirements into themes. A stakeholder meeting works well for grouping requirements, just like it works for creating requirements. You can group features by usage flow, technical similarity, or business need.
Qquestions to consider when grouping your requirements:
How would customers use the product?
If we offered this requirement, what else would customers need to do? What else might they want to do?
Can the development team identify technical affinities or dependencies?
Use the answers to these questions to identify your themes. Then group the features by these themes. The themes in a mobile banking application may be the ones shown as sticky notes on whiteboard here:
Step 3: Estimating and ordering the agile product's features
After you identify your product requirements and arrange those requirements into logical groups, you estimate and order the requirements. A few terms you need to be familiar with for this step include:
Effort is the ease or difficulty of creating a particular requirement.
An estimate, as a noun, can be the number or description you use to express the estimated effort of a requirement.
Estimating a requirement, as a verb, means to come up with an approximate idea of how easy or hard that requirement will be to create.
Ordering, or prioritizing, a requirement means to determine that requirement's value in relation to other requirements.
Value means just how beneficial a particular product requirement may be to the organization creating that product.
Scoring requirement value and effort
To order requirements, you must first estimate a score to represent the value and effort for each requirement. To order your requirements, you also want to know any dependencies. A dependency is a requirement needed before another requirement. For example, if you have an application that needs someone to log in with a username and password, the requirement for creating the username would be a dependency for the requirement for creating the password, because you generally need a username to set up a password.
Estimating, or scoring, requirements on value and effort is a key first step to ordering those requirements.
You work with two different groups to score your requirements:
The product owner, with support from the stakeholders, determines the value of the requirement to the customer and the business.
The development team determines the effort to create the requirement for each requirement.
Scrum teams often use the Fibonacci sizing sequence for creating requirement scores. The Fibonacci sequence goes in a progression in which each number, except the first two, is the sum of the prior two numbers — 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, and so on.
Use your scores relatively. Choose a requirement that the project team can agree has a small value and effort, score it, and use that requirement as a benchmark. To score other requirements, decide whether other requirements have more or less value than your benchmark requirement, and whether they are easier or harder than your benchmark requirement.
You may use two benchmark requirements, one for value and one for effort. In the end, the relative score, not the absolute score, matters.
Calculating relative priority
After you have your value and effort scores for your requirements, you can calculate the relative priority of each requirement. Relative priority helps you understand how one requirement relates to another in terms of value. When you know the relative priority of your requirements, you can order them on your product roadmap.
Calculate relative priority with the formula: Relative priority = value/effort
For example, if you have a requirement with a value of 89 and an effort of 55, the relative priority is 1.62 (89/55 = 1.62), which you could round to 2 — in fact, you can round all fractional results to the nearest whole number.
Using this formula
A requirement with high value and low effort has a high relative priority. For example, if the value is 144 and the effort is 3, the relative priority is 48.
A requirement with a low value and high effort has a lower relative priority. For example, if the value is 2 and the effort is 89, the relative priority is 0.0224.
This formula usually produces fractional results. If you want, you can round those to the nearest whole number.
Relative priority is only a tool to help the product owner make decisions and prioritize requirements. It isn't a mathematical universal that you must follow. Make sure your tools help, rather than hinder.
Note the relative priority for each requirement. From here, you can review your requirements simultaneously and prioritize them.
Prioritizing requirements
To determine the overall priority for your requirements, answer the following questions:
What is the relative priority of the requirement?
What are the prerequisites for any requirement?
What set of requirements belong together and will constitute a solid release?
Using the answers to these questions, you can place the highest-priority requirements first.
Your prioritized list of user stories is called a product backlog. Your product backlog is an important agile document, or in agile terms, an artifact. You use this backlog throughout your entire project. With a product backlog in hand, you can start adding target releases to your product roadmap.
Step 4: Determining high-level agile time frames
When you first create your product roadmap, your time frames for releasing product requirements is at a very high level. For the initial roadmap, choose a logical time increment for your project, such as a certain number of days, weeks, months, quarters (three-month periods), or even larger increments. Using both the requirement the priority, you can add requirements to each increment of time.