In my last post, I talked about the elements of an Agile roadmap. Agile roadmaps are never conclusively finished. They change according to regular review by the core team, in addition to the product manager. This flexibility means that every team member for each core function can be held accountable and responsible for helping to keep the map updated. Agile teams anticipate and are prepared for their roadmaps to change. Roadmaps are a reference guide for any decisions about release planning, backlog, and outbound marketing efforts. They provide a visual breakdown of product strategy and maintain focus. As such, they are an essential addition to any executive wall or conference room.
When the most appropriate release window has been set and the overall plan has been given the go-ahead by all stakeholders, teams can start release planning. Release planning takes place over a concentrated two- to three- day collaborative working session among the entire team, the end result being more accurate estimates as to the amount of effort needed to tackle the whole backlog of work for a given release. This can seem difficult as the team has to highlight high-level goals, features, and the value proposition for a release and then break down these requirements into use cases and features, with the eventual aim of producing user stories that a development team can realistically estimate. Agile teams rapidly adjust to this specialized means of accurate release planning.
During the release cycle, the roadmap will be adjusted and updated according to a variety of different factors. Should overall company strategy or development status change, based on voice-of-the-customer programs or information from other sources, these changes can be integrated into the roadmap. This makes the roadmap a handy measure of the non-stop planning in an Agile development environment, able to take on new information from all quarters (top-down, bottom-up, or even outside-in) and adjust accordingly.
