The map of the Great Wall is an information radiator.

The map of the Great Wall is an information radiator.

One of the most powerful concepts championed by the Agile movement has been the use of information radiators as communication vehicles.   Alistair Cockburn defines information radiators as “a display posted in a place where people can see it as they work or walk by. It shows readers information they care about without having to ask anyone a question. This means more communication with fewer interruptions.” The goal of these tools is to increase access to information through transparency. Agile Story Maps are information radiators. The goal of a Story Map is to present the big picture of the project in assessable manner for everyone on the team. The Story Map’s ease-of-use and transparency increase the likelihood of collaboration and feedback within the team. The Story Map is also a tool to visually plan releases. The first step is to create an Agile Story Map.

Agile Story Map Version 2

Agile Story Map Exhibit Version 2

Here’s the process (assuming that you’re not starting with an existing backlog).

Story Generation/Grouping

  1. Gather a cross disciplinary team of 3-7 people that understand the purpose of the product. The team should include a mix of business and technical perspectives. The team size should constrained because as it grows the amount of discussion will increase faster than value.
  2. Have the team identify the marketable features of the project/application.  I use silent brainstorming; each person silently writes down one marketable feature per sticky note. Once everyone has finished writing their post-its, have each person read their sticky note aloud and place them on the table in front of the group. If anyone has duplicates they should be removed at this point.
  3. Next have the team group/rearrange the sticky notes without talking (affinity diagramming). Move things that are similar to each other closer to each other and things that are dissimilar to each other should be moved farther apart.
  4. Name each group and place another color of sticky with that name above of the group. These are the Epics. The facilitator should lead this this step interactively.
  5. Arrange the groups left to right in the order that they would naturally occur (user visible functionality or batch).
  6. Review/walk the skeleton (term coined by Jeff Patton) to validate completeness in terms of user tasks or activities. The goal of this process is to identify holes in the story map based on the knowledge the team currently has available.
  7. Break each epic or user task down into more detailed user stories or activities (I use a rule of thumb to break that stories should be broken into thin slices that can be completed during a sprint).

 Prioritization: There are several strategies for prioritization.

  1. Business Value – assign business value to each story in the map. The Product Owner generally leads this effort. Prioritize the highest value first.
  2. Risk and Complexity – assign a level of risk and complexity for each story.  The technical team members will generally have significant input into this discussion. Prioritize risk and complexity higher.
  3. Perceived Dependencies – Tweak prioritization to reflect dependencies. The technical team members will generally have significant input into this discussion
  4. Combination – Combine all three (my favorite approach).  Generally I prioritize by risk then value and then dependencies.  This engages the whole team in the discussion and front loads risk as a mitigation technique.

Based on the prioritization strategy, review each user story and assign it a priority.  I use the nomenclature of dollar value and a high, medium or low risk/complexity (i.e. $4000,H).  It is very difficult to precisely define the business value of each story, the actual dollar value is less important than assign a relative value for each story.  Knowing the relative value will provide the team with an understanding of which stories will provide more value. After assigning a value to all stories, sort each list from highest to lowest and roughly aligning stories of similar value.  When two stories have the same or nearly the same value they will be placed together (example in Column three in the exhibit above).

Story mapping is a relatively simple process that organizes the backlog. The story map is an Agile information radiator because it provides the team and stakeholders with information with them having to ask or dig. An Agile Story Map provides the big picture of the application and the priority of each of the stories.  Tomorrow we will use the prioritized map to generate a release plan.

The Great Wall of China was a program.

The Great Wall of China was a program.

Scaling Agile project management to large, complex endeavors requires an Agile Program Manager to address the big picture coordination of programs.  Program management is the discipline of coordinating and managing large efforts comprised of a number of parallel and related projects. Scrum leverages a concept called the Scrum of Scrums to perform many of the activities need for program management.  Agile Program Management is not just repurposed project management or a part-time job for a Scrum Master.

Agile Program Managers coordinate and track expectations across all projects under the umbrella of the program, whether the projects are using Agile or not. Coordination includes activities like identifying and tracking dependencies, tracking risks and issues and communication. Coordination of the larger program generally requires developing a portfolio of moving parts at the epic or function level across all of the related projects (epics are large user stories that represent large concepts that will be broken down later). Agile Program Managers layer in each project’s release plans on top of the program portfolio to provide a platform for coordinated release planning. Techniques like Kanban can be used for tracking and visualizing the portfolio.  Visualization show how the epics or functions are progressing as they are developed and staged for delivery to the program’s customers.

Facilitating communication is one the roles of an Agile Program Managers. The Scrum of Scrums is the primary vehicle for ensuring communication.  The Scum of Scrums is a meeting of the all of the directly responsible individuals (DRIs) from each team in the program. The DRI has the responsibility to act as the conduit of information for his or his team to the Agile Program Manager and other DRIs. The DRI raises issues, risks, concerns and needs. In short, the DRI communicates to the team and the Scrum of Scrums. The Scrum of Scrums is best as a daily meeting of the DRIs chaired by the Agile Program Manager, however the frequency can be tailored to meet the project needs.  A pattern I have seen used to minimize overhead is varying the frequency of the Scrum of Scrums based on project risk.

Another set of activities that generally fall to the Agile Program Manager is the development and communication of program status information. Chairing high-level status meetings, such as those with sponsor or other guidance groups, is a natural extension of the role. However this requires the Agile Program Manager to act as a conduit of information by transferring knowledge from the Scrum of Scrums to the sponsors and back again. Any problem with information flow can potentially cause bad decisions and will affect the program.

We will explore the role of the Agile Program Manager in detail. For now, it is important to recognize that the Agile Program Management is more than a specialization within the realm of project management or a side job a Scrum Master can do in his or her spare time.  Agile Program Managers need to be well versed in both Agile techniques and in standard program management techniques because the Agile Program Manager is a hybrid from both camps. Agile Program Managers build the big picture view that a portfolio view of all of the related projects will deliver. They also must facilitate communication via the Scrum of Scrums and standard program status vehicles.  The Agile Program Manager many times must straddle the line between both the Agile and waterfall worlds.


Recently my wife and I hiked the Jinshangling portion of the Great Wall of China, which was originally built during early in the Ming Dynasty. It was then later restored into what we now recognize as one of the most iconic portion of the Wall under Ming General Qi Jiquang. While the project to build the great wall was not exactly Agile and probably did not foster participatory management, this section of Wall is said to reflect the vision of Qi Jiquang, its product owner, which was different than other sections of the Great Wall. According to guides in the area, Qi Jiquang was based in the area and used his well-fed troops to build the wall (rather than other forms of staffing/servitude elsewhere). Qi Jiquang lived and interacted with his men on a daily basis in other sections of the Wall absentee product owners prevalent. Absentee product owners can’t provide their vision or motivate the team something that the great general knew.

Looking out at the some of the most iconic views of the Great Wall drives home the point that when IT and business work together to achieve a well-crafted vision, great things can happen.