To visualize sprint progress in a scrum, a board is used that came from kanban. Kanban (kan-visual, ban-card, board) is a logistical tool of the Just In Time concept, which was introduced in the early 20th century in the Toyota concern and later in many other companies. Kanban is the cards that were in each container of parts.
When production consumed parts from a single tare, the card was sent along with the tare to a warehouse or component production, where the tare was refilled with these parts. There were different cards for each component. With this “pulling” approach, precisely as many parts were produced and ordered as we’re consumed by current production at a given rate. Output, in turn, was regulated by demand. In this way, warehouse and workplace inventories were reduced to almost zero, which reduced storage costs and reduced capital tied up in inventories.
The sprint cards (tickets) are usually stickers or any other pieces of paper that contain the story ID from the backlog, a brief description of the story, its priority, and a score in story points (SP).
If the grade changes during the work, the old grade is crossed out and the new grade is written. In this way, you can see how many times and in what way a grade was changed. The artist can’t change it unnoticed.
It is convenient to use cards of different colors for different types of stories. Sometimes the card also has the name of the person in charge on it.
At Toyota workplaces, kanban cards were counted on special boards that showed their turn and status.
Sprint adopted and adapted this approach. A typical Sprint board looks like this:
Its basis is 3 columns, separated by a line and cards of stories and tasks, which are attached to the board with magnets, buttons, a sticky layer, etc.
The “In Plan” or “Not Started” columns are stories that are planned for the sprint but have not yet been started. At the beginning of the sprint, this column is the backlog of the sprint.
“In Progress” or “In Progress” is what is being worked on.
The “Done” or “Done” column contains stories that are finished and meet the readiness criterion.
Each company may have additional columns that reflect the specifics of its production process: testing, reviews, etc.
The cards are arranged vertically according to priority. At the top is the highest priority, and the rest are arranged in descending order.
Each person to whom a story or task is assigned moves his or her card according to the state of affairs.
The scratchboard is overseen by a scratch master. He initially places all the cards in the sprint backlog column. When the sprint ends, before starting a new sprint, he removes all cards from the board. In some teams, the scrum master, following the tradition of kanban, makes sure that no more tasks than agreed upon are piled up in the execution phase. For example, no more than 4 tasks per team member or no more than 15 tasks for all.
If this limit is exceeded, no one can start a new task and put it in the “In Progress” state. The freed team member must instead pick up one of the “in progress” tasks and get it moved to the next state, e.g. bring it to readiness. Only after that can a new task be started. The point of this restriction is not to find yourself with a lot of “almost done” work at the end of the sprint. From the customer’s point of view, “almost done” is a lack of results. And from the point of view of production, a task in progress is tied-up capital.
It is useful to write down the goal of the sprint in the appropriate sector to keep it in front of you at all times.
In the course of a sprint, it happens that to implement the planned stories, it becomes necessary to do work that was not foreseen. If this only comes to light during work, such omitted tasks in the plan are placed in the Unplanned sector. As team members are released, they take these tasks apart if possible.
Next – here are the cards of the planned stories that are next in priority in the product backlog. On those rare occasions when the entire sprint backlog is done and there is still time before the end of the sprint, the team takes the cards from here. To use this feature, the product owner during grooming needs to make sure that there are stories above the sprint, described, and ready for implementation.
Burndown – contains a “burnout chart” which we’ll look at in the next session.
As far as the board itself is concerned, ordinary marker boards that are often found in the office work well. They use magnets to attach cards to them. But if you don’t have a whiteboard, you don’t have to buy one. Especially if you’re just trying out scrum and aren’t sure if it will stick with you. I have seen boards made of sheets of plywood, foam plastic, and wadding attached to the wall. Office pins are suitable for attachment.
Even glass walls of office partitions can be used by gluing cards to them. I don’t recommend relying on regular stickers, as they easily peel off after a few moves and crumble down in a leaf fall. We had a case where the janitor swept up and threw away some of the sprints, which to her were just pieces of paper that were lying on the floor. There’s a joke among sticker supporters that a fallen sticker doesn’t need to be picked up. If it’s fallen, it’s been hanging for a long time. If it’s been there a long time, you don’t need it anymore 🙂
Keep in mind that the longer the sprint and the larger the team, the wider the board you need so the cards are not crowded on top of each other.
Of course, there is software that allows you to use virtual boards and cards. This provides several conveniences such as searching, filtering, easy movement, limiting the number of tasks in progress, etc. For example, in ALM Devprom, when you move a card on a board to a specific column, you can even set automatic action to be performed, such as changing the executor to a tester when moving to the testing stage.
The advantage of real boards is that high transparency of the process is achieved. It is visible not only to the participants but also to everyone who enters the office. This motivates team members to move their cards promptly. On the other hand, if competitors or random people come in, think about whether they need to see what you are working on at the moment. 🙂