…Sprint Planning has ended with the Product Owner and the Development Team agreeing on a Sprint Goal. The Development Team has forecast what Product Backlog Items (PBIs) it believes 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 replan 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” ([1]). 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.
Compare the Self-Managing Team with the situation of a military commander. We can define the strategic direction in terms of the Sprint Goal and, to a lesser degree, in terms of completing work on the PBIs as per the Development Team’s forecast for this Sprint. The PBIs are often an approach to achieving the business imperative of the Sprint Goal, and tasks or work items are tactical objectives towards delivering the PBIs. They are the team’s chosen path to completing the PBIs. The Development Team may plot this path at the beginning of the Sprint Backlog, but progress brings increased clarity that frustrates the best laid plans of mice and men. So the team must frequently revisit their tactics.
Collaboration between people with different functional backgrounds is much harder without transparency. Individual Development Team members need constant reminders 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.
Therefore:
Create a Scrum Board that represents the Sprint Backlog and its evolution during the Sprint. The Development Team maintains it, controls it, and owns it. 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; it relates development tasks and other Sprint Backlog Items to Product Backlog Items, and PBIs to the Sprint Goal to which they contribute.
✥ ✥ ✥
The team can now visualize the state of tactical work on tasks together with PBI completion status, and can use specific task status to determine if they are still on track or if they need to update the work plan to complete PBIs or to meet the Sprint Goal. If the team can visualize progress on the Sprint Backlog, it makes such replanning easier.
The team can post a statement of the Sprint Goal and a Sprint Burndown Chart along with the Scrum Board ([2], pp. 356–58).
The Development Team collectively owns the Scrum Board, and typically updates it as the team completes 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 the 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.
Where possible, it is a good idea to hold the Daily Scrum around the Scrum Board because then the Development Team can create the daily plan with the latest information available.
Scrum does not prescribe the format of a Scrum Board ([3]). It is for the team to decide the most useful way of presenting the information it needs. It should be possible for all developers to view and manipulate the board together as a team. A small computer screen works against this, and moving items with a keyboard or pointing device is awkward even if the screen is large. The best Scrum Boards are tactile and use simple “technologies” such as sticky notes or whiteboards. The following describes just one example:
- The board is a large poster displaying a matrix. Cards and sticky notes represent PBIs and Sprint Backlog Items, respectively. The team moves sticky notes across the board to represent its progress to Done (see Definition of Done).
- The board prominently displays the Sprint Goal as a named state, or as a short statement explaining how it benefits the end user.
- The chart has a row for each PBI in the current Sprint. There is one column each for PBIs; for Sprint Backlog Items ‘To Do’; for Sprint Backlog Items ‘In Progress’; for completed Sprint Backlog Items; and ‘Done’ for PBIs that are Done.
- Cards representing the PBIs start in the PBI column and the team moves them to the ‘Done’ column only when it completes all the Sprint Backlog Items for it, and it meets the Definition of Done. When Development Team members start a task, they move the sticky note that represents it to the ‘In Progress' column. When they complete a Sprint Backlog Item, they move its sticky note to the ‘Done’ column and the developers who worked on it can now pick up a new one.
- The Development Team has met its forecast when all the PBI cards have reached the ‘Done’ column.
- Each Scrum Board lasts for the length of the Sprint. New Sprints require that the team create a new Scrum Board or that an existing Scrum Board be reset.
This pattern is an Information Radiator and is related to the Sprint Burndown Chart.
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. A Self-Managing Team owns and controls a Scrum Board: it does not control them. It is a tool that allows the team to plan, and replan as necessary, how to meet its 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 (and multiple teams may work on it), to the point where a team delivers the feature to the customer. Each state has a Work-In-Progress (WIP) limit associated with it. Advocates of Kanban (in software development; see [4]) 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 any set of tools can capture. 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.
[1] Sir Lonsdale August Hale, Col. (ret). The Fog of War. London: Edward Stanford, 1896.
[2] Kenneth S. Rubin. Essential Scrum: A Practical Guide to the Most Popular Agile Process. Reading, MA: Addison-Wesley Signature Series (Cohn), 2012. pp. 356–58.
[3] Thomas P. Moran, Eric Saund, William van Melle, Anuj U. Gujar, Kenneth P. Fishkin, and Beverly L. Harrison. “Design and Technology for Collaborage: Collaborative Collages of Information on Physical Walls.” Proceedings of the 12th annual ACM symposium on User interface software and technology, ACM press, 1999, pp. 197-206.
[4] David J. Anderson. Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press, 2010.
Picture credits: The Scrum Patterns Group (Mark den Hollander).