You are on page 1of 4

11"Big"Visible"Charts"HD"Preview.

" "

"

Okay. Welcome to the Agile program fundamentals module on


big visible charts. Big visible charts are exactly what
you'd think they'd be. They're big, visual representations
of project information posted up on walls in an Agile team
space.

Allister Coburn, who is one of the authors of the Agile


manifesto, he calls them information radiators, because
that's what they do. They radiate information related to
the work being done by the team out to those who are
interested in it.

So, they're very useful for the team because, of course,


the team is interested in its own information. And they're
also useful to people interested in the work out side the
team.

They should be big enough that someone walking by the team


space with an interest in the work can see and understand
them from a distance. And we put them up for a number of
reasons. Because we need to be on the same page as a team,
and very often, just by creating them as a team, we get
there faster to shared understanding.

And because we believe in transparency. We want people


outside the team to know what we're working on and what
issues we face. So, let's look at some common examples.

-1-
11"Big"Visible"Charts"HD"Preview." "

"

We've already talked about the value of visually


representing whole portfolios, programs, releases, and
iterations up on walls for all to see. These are all
examples of big visible charts, even if they aren't charts
in the strict sense.

We've talked about burn-up charts and we'll talk about them
more in more detail shortly. And there are also burndown
charts, which teams use to track their progress within a
duration and to determine when course correction is
required. It's also common to see Agile teams have big
visible charts representing issues and risks and even
architectural plans.

People may be familiar with Kanban boards. Kanban is


literally sign board or billboard in Japanese. This
practice came from Toyota and the Toyota production system,
which we can trace back to the 1940s.

Teams visually represent the process they follow to produce


things from start to finish and each step in the process is
represented by a column. Pieces of work, which are
represented by cards, they move across the board from new

to done.

One of the interesting things that happens here is WIP, or

-2-
11"Big"Visible"Charts"HD"Preview." "

"

work in progress limits that are enforced. As cycle time


from new to done is measured, teams limit how many items
can be in a given column at any time, which encourages them
to move individual pieces of work to done as quickly as
possible.

Many Agile teams have task boards that they use in exactly
this way to manage their work over the course of an
iteration. So, Kanban boards are another example of big
visible charts.

We mentioned burnup charts earlier, and here's one. When


teams have estimated all the work to be completed on a
project and story points, they can sum up those points to
come to a total number for the project, and then they burn
up to that number over time based on their actual velocity,
iteration by iteration.

If the amount of scope to be delivered changes or if their


velocity changes, burnup charts can help teams assess the
impact to time and cost and then respond appropriately.

We talked about stakeholder analysis and mapping during the


discovery practice. Stakeholder maps make great big

visible charts for teams as they manage stakeholder needs


and expectations. Here we have a standard, four-quadrant
chart used to map individual stakeholders or groups of

-3-
11"Big"Visible"Charts"HD"Preview." "

"

stakeholders against their influence and impact.

Here's another four-quadrant BVC, this time mapping project


risks against probability and impacts. Teams can develop
these collaboratively and collectively and then focus on
the most important risks first -- i.e., those with the
greatest probability and impact.

And then finally, here's a BBC we call an issues bulls eye.


As issues come up, the team places them in the bulls eye
according to severity. The more severe the issue is or the
more important the issue is to resolve, the closer to the
center of the bulls eye it's placed.

Project managers and iteration managers can look at an


issues bulls eye created by the team and know immediately
where to focus their energy.
[END OF SEGMENT]

-4-

You might also like