The value stream

Making work visible

A team that cannot see where its work stands decides on impressions, and those impressions differ from one person to the next. Four patterns from A Scrum Book describe how to display useful information, follow the Sprint day by day and tell apart what informs from what calls for immediate action. The Scrum Guide requires none of these tools, and each of them can turn against the team if it is used to watch over it.

Ten seconds in front of a whiteboard

In the nurses' station of a surgical ward, a large whiteboard covers one wall. Each row stands for a room and shows the day of the operation, the tests still awaited and the expected discharge date. The nurse starting her shift, the doctor passing through and the ward manager know in ten seconds which beds will become free and which patient is still waiting for a scan. Nobody had to call a meeting or open a piece of software to get this result.

Scrum teams look for the same effect in their own work. The Scrum Guide makes transparency the first pillar of empiricism: you can only inspect and adapt what you can see. A Scrum Book devotes four patterns to this question.

Information Radiator: information that comes to you

The Information Radiator pattern starts from an observation: an organization deprived of reliable, recent information makes bad decisions. The authors illustrate it with the loss of the Challenger space shuttle in 1986: the commission of inquiry found that warnings about a known defect in the boosters had been ignored.

Several forces work against sharing. Keeping what you know to yourself takes less effort than spreading it, and a busy developer soon sees reporting as a chore foreign to the job. Status meetings cost time. Too much data has the same effect as too little, because readers end up no longer looking. Finally, information loses value over time: learned too late, it only serves to show that decisions were made without it.

The solution is to maintain, together, physical displays that keep the information visible to all stakeholders. The book gives a few rules for building them:

• design the display with the people who need the information, accepting that the first version will be bad;
• remove without regret whatever is not used;
• prefer a simple, hand-made display that is cheap to keep up to date;
• put it where people cannot avoid seeing it;
• and keep it changing, otherwise it becomes wallpaper that nobody reads anymore.

The authors are hard on software tools, which they say make for "information refrigerators": the information is kept there, but you have to go and fetch it. They add two requirements. You need the courage to display bad news, and you must never use a display to single out a culprit.

The book gives as examples the Scrum board, the Sprint burndown chart and the list of obstacles kept by the Scrum Master (the Impediment List). It links the idea to the "visual control" of the Toyota Production System and credits the term information radiator to Alistair Cockburn, who coined it in 2001.

Scrum Board: the Sprint plan on a wall

The Scrum Board pattern comes right after Sprint Planning. The Developers have a plan, the Sprint Backlog, and each of them is moving forward on their part. The problem is that, as a group, they may lose sight of the Sprint Goal. The authors borrow from the military the image of the "fog of war", which arises less from a lack of information than from too many disparate reports in a fast-changing situation. People from different trades collaborate poorly if they cannot see how their tasks connect to the common goal.

The solution is a board that shows the Sprint Backlog and how it changes during the Sprint. The Developers keep it up to date and are its sole owners. It links the tasks to the Product Backlog items (PBIs), and these items to the Sprint Goal. The book points out that Scrum imposes no format and describes one example: a row per item, and columns "to do", "in progress" and "done" across which sticky notes are moved. The item itself only moves into the last column once all its tasks are finished and it meets the Definition of Done. The authors advise holding the Daily Scrum in front of the board.

The authors distinguish this board from a Kanban board, which tracks each item through all its states up to the customer, with a work-in-progress limit for each state. They also point out that putting up a board is not enough to "do Scrum": kicking a ball around in a park looks like football without being football.

Sprint Burndown Chart: the slope left to go down

The Sprint Burndown Chart pattern answers a tension. The forecast made at Sprint Planning contains too many unknowns to count as a guarantee, but it has created expectations among stakeholders. The Developers need to know, almost every day, whether they are on track to meet it. If they overestimated their capacity, they should warn people early. If they underestimated it, the Scrum Team must decide what to do with the spare capacity.

The solution is a chart with the estimated remaining work on the vertical axis and the days of the Sprint on the horizontal axis. The slope of the curve gives an immediate indication. A straight reference line is often drawn from the initial total down to zero: a curve well above it signals an unfinished Sprint, a curve well below it signals some slack. The authors note that the real descent is rarely linear and that a comparison with previous Sprints would be fairer. According to the book, Ken Schwaber described this chart in May 2001, after inventing it at Fidelity Investments.

The pattern recommends counting finished items rather than tasks. The curve only goes down when an item reaches the Done state, by the value of its original estimate, and it goes up if the team discovers unplanned work. Nothing is deducted for a half-finished item, because a team can complete many tasks without delivering any value. The book insists on one last point: the chart belongs to the Developers, it was designed for them and not for management, and it is better drawn by hand.

Visible Status: when a display must trigger action

The Visible Status pattern deals with a weakness of information radiators: people get used to them. The authors recall that paying attention to one goal makes you blind to everything else, and cite the experiment by Daniel Simons and Christopher Chabris (1999), in which viewers busy counting passes of a ball fail to notice a person in a gorilla suit walking across the scene. They tell the story of a team that looked at its burndown every morning and then carried on with its plan unchanged, even when the curve stayed flat. This, they write, is like the service reminder on a car dashboard that you ignore for months, whereas the oil warning light makes you stop the car on the spot. A team needs both kinds of signal.

The solution is a status indicator that demands action as soon as a quantity goes outside the accepted tolerance: a red light, a warning word or a lock on the workstation. This assumes that the team has discussed what it calls the normal state, and that it knows what to do when the signal goes off and how much time it has. Indicators should be very few, and the team removes those that no longer serve it. The action can be set in advance: fix a defect immediately, or trigger the emergency procedure described in the article on protecting the Sprint when the Sprint strays too far from its plan.

A doctor's office offers a simple example of the difference. The log sheet stuck on the vaccine fridge is an information radiator: it shows the temperature history to anyone who wants to read it. The alarm that sounds when the temperature leaves the range of +2 °C to +8 °C is a visible status, and the instruction posted next to it says what to do. In a software development team, the usual equivalent is a lamp that turns red when the automated tests fail. A team can agree that, as long as the lamp is red, nobody integrates a new change and the author of the last one deals with it at once.

This pattern also comes from Toyota, where the andon cord lets an operator signal a defect and get help, up to stopping the line if the problem persists (see Andon and poka-yoke, in French). The authors add a warning: anyone who uses these indicators to name "the best team" should think twice.

What the 2020 Scrum Guide says

• The Guide prescribes neither board nor chart. It asks that the Sprint Backlog be a highly visible, real-time picture of the work the Developers plan to accomplish, detailed enough for them to inspect their progress at the Daily Scrum.
• It mentions burn-downs, burn-ups and cumulative flow diagrams as useful practices for forecasting progress, adding that they do not replace the importance of empiricism: in a complex environment, only what has already happened can be used for decision-making.
• The 2017 edition asked the Development Team to track the remaining work at least at every Daily Scrum. The less prescriptive 2020 edition removed that sentence.
• The book says "Development Team" and "ScrumMaster"; the 2020 Guide says "Developers" and "Scrum Master". The Impediment List is a pattern from the book and not an artifact of the Guide.

Limits and pitfalls

The first pitfall is the stale display. A board that is no longer up to date misleads more than no board at all, because people go on trusting it.

The second has to do with the medium. The book, published in 2019, has in mind a team working together in one room. A team spread over several sites uses a digital board (see stable, co-located teams). The authors' criteria then serve to judge the tool: can everyone see the whole thing at a glance, and can several people work on it at once?

The third is surveillance. A burndown consulted by a manager to compare teams or assess individuals stops informing, because everyone starts massaging the curve. This is the mechanism of Goodhart's law (in French). The pattern on the spirit of the game counts among the betrayals of Scrum the use of a tracking tool to rate individuals.

Finally, these recommendations come from practitioners' experience. The book draws on research in the psychology of attention to justify warning signals, but it cites no controlled study showing that a board or a burndown improves a team's results. The corpus's critical article returns to this point.