Visualizing and sharing project status

September 20, 2007
URL:http://www.drdobbs.com/architecture-and-design/visualizing-agile-projects-with-kanban-b/201807863

Kenji Hiranabe is CEO of ChangeVision and can be contacted at [email protected].

Extreme Programming (XP) has a practice called "informative workspace" where you can see how the project is going on at a glance. A primitive way of doing this is just putting story cards or task cards on the wall. Other graphs and charts on the wall are sometimes called "information radiators" or "Visible Big Charts" and have became common in today's agile project rooms. In this article, I present examples of the visualization found in agile teams in Japan.

The first example in Figure 1 is a Task Kanban Board named after Just-In-Time production method in Toyota Production System (TPS).

A Kanban is a ticket describing a task to do. In TPS, it is used to realize Just-In-Time "pull" production control. In Figure 1, the Kanban Board shows the current status of all the tasks to be done within this iteration. The tasks are represented by cards (Post-It Notes). Status is presented by areas on the board separated and named ToDo, Doing, and Done. This Kanban Board helps team understand how they are doing, as well as what to do next. This helps make the team self-directing.

Figure 2 is another type of Kanban Board, called "Feature Kanban Board."

The horizontal axis of this chart is a timeline and vertical areas in the timeline represent releases. Each card posted represents one feature to be implemented in the release. Contrary to the first example which is usually used within development teams, this Feature Kanban provides a high-level overview of the product's road map so it should be shared with the whole team -- including customers, marketing staff, and managements.

Also, a "Parking Lot Chart" like Figure 3 is used to provide a top-level digested summary of project status. It is first described in Feature-Driven Development and is widely used in agile projects today.

Figure 4 is another type of visualization -- the "Burndown Chart".

Burndown charts were first described in SCRUM to show remaining backlogs. They've now spread to most agile projects. They've captured the current status as well as the progress of consuming the remaining tasks.

The last interesting visualization (Figure 5) is called "Niko-niko Calendar" (or "Smiley Calendar") and was born in Japan. Niko-niko Calendars show a team member's mood for that day.

Everyone puts a Smiley mark onto a calendar after the day's work, before leaving the team room. It looks at the project from member's mental health and motivation viewpoint.

Kanban Board as Primary Information

In short, there are many types of visualizations:

• Kanban Boards. Use a card as a token (Kanban) of a task, story, feature, and stick them to a timeline (board). There are several levels of granularities.
• Burndown Charts. Count the number of Kanbans (backlog tasks) and track it in a timebox to show the trend of backlogs being consumed. There are also several levels of granularities.
• Parking lot Charts. Summarize the top-level project status.
• Calendars. Other than Niko-niko calendars, there are a lot of variations of using calendars to show project status or plan.

Among Kanban Boards, Burndown Charts, and Parking Lot Charts, Kanban Boards have the most detailed information. Burndown Charts and Parking Lot Charts can be drawn using the information of daily changing Kanban Boards. So hereafter I'll discuss Kanban Boards as main information radiators, and Burndown Charts and Parking lot Charts as sub-tools which summarize Kanbans visually.

Organizing Kanbans from Three Perspectives

Looking closely at Kanban Boards, you find three things expressed on them -- time, task, and team. Here I organize Kanbans from these three viewpoints:

• Time. In agile projects, time of a project is first broken into "Releases" and each release into "Iterations", and each iteration into "Days". A release is typically 1- to 6-month long and is the most coarse-grained timebox. It is a sync point of the whole team so everyone in the whole team should be interested in it. An iteration is the second level timebox. It is typically 1- to 4-week long and development teams use it as a major working, tracking and improvement cycle. And everyday is the most fine-grained timebox, the team gets together in a stand-up meeting to share project status and problems.
• Task. There are also three levels "Tasks" in granularity. Here I call the top level "Features" and each feature is broken down into "Stories", and each story into the lowest level "Tasks". A feature is a function useful meaningful to users. A story is a testable piece of a feature, also described by words of users. And a task is a work unit of a story, commonly described by words of developers.
• Team. A project team consists of people working toward the same goal. Typically, a manager, customers, developers, business analysts, users, testers and other stakeholders should be members of the team. The whole team should share information of time and task to achieve the project goal.

Mapping Task to Time

Here I'd like to define a Kanban Board as a mapping between tasks and time for the team. Note that "time" and "task" both have a three-level breakdown structure, and the higher the breakdown levels are, the higher the level of management should get involved in. So, it is reasonable to set up Kanbans in combination of Release-Feature, Iteration-Story, and Daily-Task as in Table 1, although there are many possible other combinations of time and task.

A "Feature Kanban" is good at giving the whole team a high-level view of the project. And it goes with a Parking Lot Chart to show the top level status. A "Story Kanban" is at the middle level, the most widely and carefully seen in each iteration by the team, and it may be supported by an iteration Burndown Charts. A "Task Kanban" is at the lowest level, showing the current changing status daily, may be supported by a daily Burndown Chart.

TRICHORD

We have been developing an agile project management tool called TRICHORD. "TRI" means the three viewpoints -- Time, Task, and Team -- and "CHORD" means harmony.

It works as a workplace to share project status in the whole team, providing the three levels of Kanban Boards -- Feature Kanban (Release-Feature), Story Kanban (Story-Iteration), and Task Kanban (Daily-Task) -- as described in Table 1. A Feature Kanban is supported by a Parking Lot Chart, Story, and Task Kanbans are supported by Burndown Charts.

In addition, TRICHORD has a Niko-Niko Calendar service to share the team mood. It also works as a simple "twitter"-like SNS communication center in the projects.

TRICHORD is implemented on Eclipse RCP (Rich Client Platform), and optionally works with Trac (issue tracking system).

6 Acknowledgements

Mary Poppendieck reviewed this paper thoroughly and provided lots of advice and suggestions, for which I am most thankful.

References

Akira Sakata, "Niko-niko calendar", 2006 (www.geocities.jp/nikonikocalendar/index_en.html).

Kent Beck, "Extreme Programming Explained 2nd ", 2005 Addison-Wesley "Informative workspace" is a practice of XP.

Alistair Cockburn, "Agile Software Development", 2001 Addison-Wesley The word "information radiator" is first used.

Alistair Cockburn, "Crystal Clear", 2004 Addison-Wesley "Burndown/up chart" is discussed as a powerful technique.

Mike Cohn, "Agile Estimating and Planning", 2005 Prentice Hall "Burndown chart" is most deeply discussed.

Ron Jeffries, "Big Visible Chart", 2004 (www.xprogramming.com/xpmag/BigVisibleCharts.htm).
Mary and Tom Poppendieck, "Lean Software Development", 2003 Addison-Wesley

Mary and Tom Poppendieck, "Implementing Lean Software Development", 2006 Addison-Wesley. Explains Kanban in TPS and how it works as a pull process mechanism.

Ken Schwaber, et al. "Agile Software Development with SCRUM", 2001 Prentice Hall

Jim Highsmith, "Agile Project Management", 2004 Addison-Wesley. Here, Feature Kanban is called Feature breakdown structure and feature planning on whiteboard.

Stephen R. Palmer et al., Practical Guide to Feature-Driven Development, 2002, Prentice Hall. First introduced Parking Lot Chart

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.