How to Build an Agile Roadmap

In agile project management, the roadmap is the guiding document that provides the overall project plan.

It is not equivalent to a traditional project schedule (gantt chart) because it is not a carved-in-stone plan whose exact execution is directly linked to project success.  Because priorities change, the product roadmap is updated throughout the project, and this change is welcomed.

If the money runs out before the all of the items in the project roadmap are completed, an agile project may still be considered a success on the basis that the highest priority items have been completed.

What Does it Look Like?

The agile roadmap can look like a gantt chart, but a more appropriate format might be the prioritized listing of product features and components, showing the month and year they are expected to be complete:

As you can see, a stakeholder can glean what is expected to be completed, while not being committed to a rigid project plan.

How to Develop an Agile Roadmap

There are five steps to producing a product roadmap:

1. Identify stakeholders
2. Establish product requirements
3. Prioritize the product requirements
4. Estimate effort
5. Estimate release time frames

Identify Stakeholders

Each project stakeholder contributes requirements to the project.

Because the agile roadmap is the highest level of planning within the agile project, the stakeholder requirements need to be elicited and incorporated into the roadmap.  These stakeholders might include customer service, maintenance, marketing, or product end users.  It is important not to miss any stakeholders, as the smallest ones (with the most minor stakes) are the ones most likely to be ignored and subsequently trip up a project.

Establish Product Requirements

The stakeholders are consulted and requirements are elicited using several methods.

• Questionnaires
  Whether formal (SurveyMonkey, etc.) or informal (email questions), asking the stakeholder what their concerns are is the first place to start.
• Brainstorming
  All ideas are thrown onto a whiteboard, then whittled down to the most important
• Observations
  The stakeholders are observed performing their normal business tasks.
• Interviews
  A larger interview process can extract requirements in greater depth than a questionnaire can.
• Facilitated workshops
  When multiple stakeholders need to sort out conflicting requirements, getting them into the same room can be enlightening.
• Document analysis
  Doing some research into the various government records, corporate correspondence, or project records can be an excellent source of requirements.
• Prototypes
  Developing and testing a prototype is often the most expensive option, but obtains a wealth of information regarding final product requirements.

The following is a checklist of the underlying sources of project requirements:

• Business requirements satisfy the policies, procedures, or organizational culture of the parent company.
• Stakeholder requirements originate from the needs or wants of a specific stakeholder.
• Solution requirements describe certain behaviors that the solution must be able to perform.
• Transition requirements are the temporary capabilities necessary to migrate from the existing state to the future state.
• Project requirements are the project management capabilities necessary to complete the project.
• Quality requirements are the quality standards necessary to produce the product to the acceptance of all stakeholders, especially end users.
• Program requirements are the benefits that are expected to accrue to the larger, parent organization.

A well-formed requirement statement looks like this:

• When [condition], the [subject] [imperative] [active verb] on the [object] so that [outcome]

For example,

• When the map is displayed, the app must show the closest salons so that the user can choose the one they most want to go to.

Prioritize Project Requirements

The most important practical differentiator between agile and traditional project management is the prioritization of the requirements to ensure the highest priority tasks are performed first.  Instead of a rigid project plan, the requirements are prioritized according to stakeholder needs, product needs, and other requirements.

A few questions to consider when prioritizing requirements:

• How will the customer use the product?
• What does the customer think is the highest priority?
• Which feature will result in the greater number of customers/users?
• What other parallel business value do the users of this feature provide?

Estimate Effort

Similar to traditional project management, each component of the agile roadmap must be estimated and rolled up into an overall project estimate, bottom-up style.  Since agile is a collaborative rather than command and control methodology, the project team determines the estimate using one of two estimation techniques:

• Estimation poker is a relative estimation technique whereby each project team member chooses a number from the fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, 55, 89…).  In this sequence, each number is the sum of the previous two.  If a different number is chosen by different team members, the discrepancy is discussed until the team arrives at an agreement.
• Affinity estimating uses categories such as small – medium – large – extra-large to categorize the effort.

Each category is assigned a certain number of points, which are aggregated to determine the estimate.

If a budget estimate is required, the project manager or scrum master must produce one based on the relative estimates determined using these methods.

Estimate Release Time Frames

The seventh principle of agile development states:

• Working software is the primary measure of progress.

As part of the agile roadmap, a release plan is determined which defines when the product releases to the market will take place as well as the features that will be included.

With each release, the minimal marketable features are determined and a product launch date is set, around which the project team can mobilize.