Develop Solution Roadmap (APS09)

Description

The Solution Roadmap is a living artifact and a way for Agile teams to keep track of all the various milestones, features, and dependencies that the team will encounter in the course of the project so that they can always present a point-in-time view of when the planned features will be delivered, both to stakeholders and to the PMO.

As with the backlog, the Solution Roadmap should seek to be an expression of adaptive planning (see above).  Since in Agile we only commit and plan for what is immediately known, it may seem contradictory to create a detailed “Roadmap” for delivery, but using adaptive planning, the concept becomes much more useful and operates by providing high, medium, and low certainty about what features will be delivered when.

• First/Current Release (Committed) – High Certainty

  • User stories

• Next Release (Planned) – Medium Certainty

  • Some user stories

  • Epics

• Beyond (6 or more months out) – Low Certainty

  • Epics

  • Some Themes

• Project Manager

• Delivery Manager

• Product Owner

• Scrum Master

• Scrum Team

• Agile Coach (if needed)

• Auxiliary Groups (see above)

Mechanism

• Meetings

• Updated Solution Roadmap artifact

Frequency

Maintained on an ongoing-basis throughout the project.  At minimum, updated in the course of each sprint to reflect changes to feature estimated delivery timelines.

Outcomes

A first iteration of a Solution Roadmap, including the following:

• Planned Releases

• Planned Sprints

• Testing cycles that are outside sprints

• Auxiliary Touch point Rhythms

  • Security

  • UX/Usability

  • Enterprise Architecture

  • Legal

• External Dependencies

• Solution Backlog Slotting/Mapping to Sprints

  • NOTE:  Per the description above, this can be in a manner conducive to adaptive planning.  Such as having user stories slotted for the next release, epics for release after that, and epics/themes beyond that.

• PMO Gates

Guidelines

• Maintain the Solution Roadmap for an approximately 6-month view of upcoming scope/features.  From an Agile perspective, anything beyond a 6-month outlook should be considered uncertain

• Make it clear to stakeholders that the farther in the future a slotted item is, the lower the certainty of its delivery in that range

  • NOTE:  This does NOT mean that those initial timelines will not be achieved.  Rather, it is to suggest that business requirements might change, and might cause items farther out to be re-prioritized higher or lower

• Have your team focus on its commitment for one release at a time.  From a planning perspective, it is ok to think ahead and figure out where your backlog items will be slotted, but in Agile the focus should always be on the immediate delivery

• Keep your focus on adaptive planning. Worry about the details for items “sooner” on the roadmap rather than items “later” on the roadmap

• Use your backlog grooming meetings and sprint planning meetings as your project proceeds to ensure your roadmap is up-to-date

• Get input from the Scrum Team as to where items should tentatively be slotted. Since they will be the team building the solution and providing the estimates, they are best capable of predicting when certain features/backlog items might be finished

• To determine how many sprints and releases total are needed for development, start by having your Scrum team (developers and testers included) size the entire backlog using planning poker.  Then, use either historical velocity data from the team or a team of that size/skill makeup (i.e. previous sprints, projects) to project a per sprint velocity.  Once that is established, project that velocity into the total backlog to determine the number of needed sprints

  • For example, if the whole backlog together makes up 200 story points, and a team of 5-7 developers has demonstrated the ability to deliver 20-25 points per sprint, then the project should plan on at least 8-10 sprints to deliver the full backlog

  • NOTE:  Some project teams want to add an additional sprint or two onto this (say 15-20% contingency), to account for potential scope additions to the backlog and due to the potential inaccuracy of estimates of backlog items that are not well-defined in early stages.  So say, 1 extra sprint for every 5 sprints it is assumed the project will need.  Worst case, the team can use those sprints to deliver scope beyond initial backlog.