Information radiators are valuable Agile tools in building transparency from the project team level to stakeholders. In short, information radiators are large and visible graphical representations of critical information about an Agile project or team. They can come in the form of a sprint task board showing the team’s progress, a release burndown chart, or metrics dashboards, just to name a few. At its core, an information radiator seeks to foster communication and provide awareness of the current state of a project.
One of the most effective ways to embed the act of radiating information into your team’s culture and practice is by building and maintaining a project wall. A project wall is enough wall space in the team’s workspace to display key information that communicates the current state of a project. Although a project wall can be built at any time, the most ideal scenario is constructing at least a first iteration of it as soon as the team is assembled for a project.
The Scrum Master or Agile Coach isn’t the only one that provides input as to what should be on the project wall. The entire team should be asked to contribute what pieces of information would be helpful or vital to share to communicate project health and progress.
What would you post on a project wall?
A project wall might include a team’s current sprint task board, story map illustrating the minimum viable product to be built, sprint burndown chart, release burndown chart, product backlog, team calendar with team member vacation schedules and key project dates, and a list of actionable outcomes from the last retrospective. We’ll dig more specifically into some of these deliverables shortly.
Where should the project wall be constructed?
The project wall should be in close proximity to the team’s workspace since the team is one of the primary consumers of the information being shared. This not only keeps the information easily accessible but also highly visible to the team to encourage keeping it current. Ideally, the team’s workspace is also in a public and accessible area to stakeholders and those who want to remain informed about the team’s progress and the project’s health.
Who maintains the project wall?
The goal is for the project wall and the items published is to be simple enough that anyone on the team could update them. The team is responsible for maintaining the project wall and for keeping it up to date.
How often should the project wall be updated?
While every item won’t follow the same cadence for being updated, the team should review frequently changing artifacts more often than those that will only change at the end of a sprint cycle. For example, the team’s sprint task board should be constantly updated to reflect the tasks and their accurate status, while the release burndown chart may only be updated at the end of a sprint.
Let’s build a sample project wall
In an effort to illustrate a more tangible example of what a project wall might look like, next we’ll pull together some of the common artifacts you might use to build a project wall. The key thing to remember is that the example below is not a prescription for exactly what a project wall should look like, but rather an idea of what you might see on a wall. There are many possibilities and options for what might be posted on a project wall depending on the size and type of the project, level of rigor required, reporting expectations from your organization or client, etc.
Sprint task board
If you are working on a Scrum project, you are likely using some type of task board to visualize and track all of the work that must be completed for each user story. Including a sprint task board on your project wall is a great way of keeping the team’s progress in a sprint visible to help team members coordinate their work, foster accountability, and serve as a visual during the daily stand-up.
Figure 1.1 sprint task board example
Sprint burndown chart
One extremely helpful graphical representation to publish on the project wall and keep updated is the sprint burndown charts. The sprint burndown shows the rate at which the team is completing or burning through the user stories committed to in the sprint, as well as whether they are on track for completing their commitment by the end of the sprint.
Figure 1.2 sprint burndown chart example
A team calendar is particularly useful in keeping not only key project dates such as release dates top of mind, but also team member schedules. By maintaining a low-tech version of the team calendar, the artifact remains constantly visible, easy to update, and aids in planning ahead for when a critical team member might be on vacation or supporting another project team.
Something that is easy to lose sight of, but critical to keep at the forefront is the release plan. This is especially important in projects that span several months or more than a year, during which it is easy to lose sight of the end goal. These artifacts can come in a multitude of formats. At the most simplistic level, it should display known releases that are planned for the project, along with any target dates.
Figure 1.3 release plan example
An Agile project wall is essentially a collection of information radiators that communicate key information about a project’s health and status. There isn’t one correct way of building a project wall, which allows for adapting it to suit the needs of your team, organization, project, or stakeholder needs. In the end, the project wall is only as useful as its information is up to date, easy to consume and understand, and reflective of key project information.