… Sprint Planning has ended with the Product Owner and the Development Team agreeing on a Sprint Goal, and a subset of Product Backlog Items (PBIs) that the team forecasts that it will deliver this Sprint. The Production Episode has started.
The Development Team has a plan expressed in the Sprint Backlog, and members of the team are applying their skills in the way they think best to accomplish the tasks in the plan. New information is continually surfacing during development, and the Development Team members are struggling to re-plan accordingly.
✥ ✥ ✥
There is a danger that the Development Team collectively will lose sight of its construction and development goals. It needs to synchronize its efforts constantly, so as to inspect and adapt the plan as required.
The phrase “fog of war” was first defined in 1896 by a Colonel in the British Royal Engineers as “the state of ignorance in which commanders frequently find themselves as regards the real strength and position, not only of their foes, but also of their friends.”  Typically, it is not so much a lack of information, but an overload of different intelligence reports, from different sources and in different formats, driven by a rapidly changing tactical situation that creates the fog. Background noise prevents a focus on the critical information in anything like a timely fashion. Information overload causes emotional overload that in turn leads to poor decision-making.
The Self-Managing Team can be considered to provide an analog to the situation of a military commander. Its line of march is best maintained by focusing on the value the Development Team has forecast that it can develop this Sprint. This is best expressed through the Sprint Goal and the PBIs the Development Team chose to work on in Sprint Planning. However, the route to these objectives that was planned at the beginning of the Sprint needs to be revisited regularly to see if it is still valid or needs updating. If the team has a visualization of progress on the Sprint Backlog it makes such re-planning easier.
Collaboration between people with different functional backgrounds is much harder without transparency. Individual Development Team members need to be constantly reminded of how their work relates to the bigger picture of the Sprint Goal, and the team as a whole needs to focus collectively on it on a regular basis.
Create a Scrum Board that represents the Sprint Backlog and its evolution during the Sprint. As such it is owned and controlled by the Development Team. Post it where all Development Team members have easy access to it as an Information Radiator.
A Scrum Board, a.k.a ‘Task Board’, is typically a big poster on a wall, that relates development tasks and other Sprint Backlog Items to Product Backlog Items, and PBIs to the Sprint Goal to which they contribute.
✥ ✥ ✥
The Scrum Board is collectively owned by the Development Team, and is typically updated by team members as they complete Sprint Backlog Items. However the ScrumMaster may want to remind the Development Team to keep the Scrum Board up to date, and will also help the team understand the significance of the data the Board is presenting. This is especially true when an incomplete or delayed development task or other Sprint Backlog Item threatens the Development Team’s ability to meet its forecast. The team can then take collective action to remove the impediment.
In short, the Scrum Board is a planning tool for action management, owned and controlled by the Development Team and, as such, can help build the necessary muscle memory needed for Development Team to become truly self-managing. Used consistently, the Scrum Board lowers the communication cost of developers trying to find out what other Development Team members are doing, and of managing the dependencies between their various tasks. Above all, it helps everyone maintain their collective focus.
The format of a Scrum Board is not prescribed . It is for the team to decide the most useful way of presenting the information it needs. The following describes just one example:
However, the Scrum Board should not be confused with a Kanban Board, despite superficial similarities. While they both depict the progress of tickets as they move through various states, the purpose is not the same. The Scrum Board is owned and controlled by a Self-Managing Team and is a tool which allows them to plan, and replan as necessary, how to meet their objectives in a Sprint.
A Kanban Board, on the other hand, maps the lifecycle of a product or a feature as it moves from inception through its various states (in which it might possibly be worked on by various different teams), to the point where it is delivered to the customer. Each state has a Work-In-Progress (WIP) limit associated with it. Advocates of Kanban (in software development ) claim that it visualizes a “pull” system where each upstream state feeds its output into the next downstream state only when there is available capacity. Kanban, however, does not mandate that teams be either cross-functional or self-managing. It leaves open who controls the board and sets the WIP limits. In these circumstances it is easy for command-and-control managements to turn the Kanban Board into a tool for a “push” system by setting arbitrary WIP limits, and pressuring developers to work to full capacity.
By contrast in Scrum, the self-managing Development Team controls work in progress by pulling PBIs from the top of the Product Backlog on a Sprint-by-Sprint basis and through swarming on the individual Sprint Backlog Items.
One last note: Laypersons often equate “doing Scrum” with the use of a Scrum board. While a Scrum Board is one of the most noticeable tools of Scrum organizations (the other being the Daily Scrum) there is much more to Scrum than can be characterized by the use of any set of tools. By analogy kicking a soccer ball around in a park can look a lot like playing soccer, but it isn’t soccer. This pattern refers to many other patterns that represent crucial components of the Scrum framework, and yet those, too, are only a starting point.
 Sir Lonsdale August Hale, Col. (ret). The Fog of War. London: Edward Stanford, 1896.
 Kenneth S. Rubin. Essential Scrum: A Practical Guide to the Most Popular Agile Process. Reading, MA: Addison-Wesley Signature Series (Cohn), 2012. pp 356-358.
 Thomas P. Moran, Eric Saund, William van Melle, Anuj U. Gujar, Kenneth P. Fishkin, Beverly L. Harrison. Design and Technology for Collaborage: Collaborative Collages of Information on Physical Walls. Palo Alto, CA: Xerox Palo Alto Research Center, 1999, CHI Letters 1(1), pp. 197-206.
 David J. Anderson. Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press, 2010.