Kanban quick-start guide

Kanban provides a simple approach to delivering high-quality value to your customers, on time and on budget. If you already have a set of work items to do and a team ready to do them (as most teams do), use this to get started right away.

The quick-start steps for using Kanban to complete your work backlog are:

• Step 1: Capture your team’s high-level routine
• Step 2: Redecorate your wall
• Step 3: Set limits on chaos
• Step 4: Define done
• Step 5: Run your daily standup

Troubleshooting
Checklist

Step 1: Capture your team’s high-level routine

Team members do many kinds of work:

• Discuss the product with partners, teammates, and customers.
• Write and answer email, and engage in relevant social media.
• Find, evaluate, and fix bugs and operational issues (tickets).
• Track feedback.
• Produce improvements to products and infrastructure.

While all this work is important, Kanban focuses primarily on the last and most intrinsic item: producing improvements to products and infrastructure. There are exceptions that Kanban can also manage, such as the following:

• Preparing for a major presentation.
• Writing proposals or major design documents, or rolling out major changes.
• Fixing a particularly complex bug or operational issue.
• Designing a response to particularly important feedback.

I’ll treat these exceptions just as I treat producing improvements. For now, let’s focus on product and infrastructure improvements. You probably already follow a high-level routine for producing improvements. Here’s the one my feature teams (3–10 people) use:

Teams that use very formal methods (perhaps for compliance) or that do in-depth design may use multiple steps to specify a work item. Teams that have complex procedures or standards may use multiple steps to implement or validate a work item. Please write down the steps familiar to your team.

Here are a few guidelines that will help you keep your routine simple:

Include only the steps that your team does Leave out the steps that occur before items reach your team (such as high-level planning or specification done by other teams) and the steps that take place after items are delivered to customers and partners. You could combine teams and include those steps, but we’re keeping things simple for this quick-start guide.

If two sequential steps are usually done by the same person, combine those steps Again, you want to keep things simple at first. If the developer for an item also usually writes unit tests, implements the code, and drives the code review, just call those three consecutive steps “Implement.” Once your work is flowing smoothly, you may want to reexamine each small step to further improve quality and throughput. Chapter 9, “Further resources and beyond” has details.

When in doubt, use the steps that I use for my teams These steps are fairly common: specify, implement, validate, and deliver.

Step 2: Redecorate your wall

Now that you’ve captured the steps in your team’s high-level routine, you need to post the steps on a signboard close to where your team resides. Your team members will use this signboard to visualize progress and attach note cards to it to track their work. (Kanban means “signboard” in Japanese, but that’s not a perfect translation. At Toyota, it means “signal card”—the note cards that track and control work. Another translation of Kanban, from Chinese, is looking at the board—thus referring to the daily standup meeting. Since these three elements are essential to Kanban, it’s a fitting, versatile name.)

You can hold the note cards in place on a whiteboard or wall by using sticky notes, tape, or magnets or attach them to a corkboard by using pushpins. One of my Xbox teams used magnets taped to the backs of cutouts of their Xbox Live avatars.

Having a signboard close to where your team resides brings up two interesting questions:

• Why not track your work using only online tools? Visualizing workflow is one of Kanban’s core principles. Without engaging with workflow in a visceral manner, team members won’t recognize and resolve issues as quickly. Manipulating note cards on a signboard is more engaging, faster, and simpler than doing so electronically. (For large organizations, your team’s project manager can quickly transfer daily status to electronic tracking tools.)
• Should your team sit together near the signboard? Teams typically work faster when team members sit in close proximity, which enables quicker, easier, and more spontaneous communication. Team members need not sit in a “team room” or in cubicles—offices in a shared hallway work just as well in my experience. Having the signboard nearby is convenient and promotes a sense of identity (“our board in our area”). Kanban can still work well for distributed teams through a virtual signboard online, but if you’re given the choice, sitting in close proximity near a physical signboard is better.

After choosing a location for your signboard, it’s time to construct two columns for each step, plus a double-width column on the left for the work backlog. The columns for each step should be the width of a note card (sticky note or index card). You can use tape or markers to delineate the columns. Here’s what your signboard might look like.

Looking back at the steps in the high-level routine that my teams use, notice how the first and last steps are treated differently from the middle steps.

• The first step, “Take an item from the backlog,” is replaced by a holding area for pending work. Note cards in the backlog are positioned in the order in which you want to work on the items (your team can reorder the cards at any time).
• The middle steps—specifying, implementing, and validating work—are divided into two columns each. The left column of each step holds active note cards (items being specified, implemented, or validated). The right column of each step holds note cards that have completed that step (items that have been specified, implemented, or validated).
• The last step, “Deliver it to customers or partners,” isn’t shown because that action is typically handled in bulk by a separate process, like integration into the main branch of a big project or a deployment to production of a web service.

Step 3: Set limits on chaos

A large part of project management is limiting the chaos inherent in group work. This step is so important that you can often identify the essence of a project-management methodology by how it limits chaos.

• In a traditional Waterfall approach, chaos is limited by specifying all the work up front, enforcing a formal change-request procedure, and synchronizing work across teams at predetermined milestones.
• In Scrum, chaos is limited by planning time-boxed sprints, withholding plan changes until the next sprint, and synchronizing with the customer at the end of each sprint.
• In Kanban, chaos is limited by directly limiting the amount of work in progress (WIP)—literally, the number of note cards allowed at each step. Simple, yet effective.

The WIP limits in Kanban serve two essential roles in controlling chaos. First, they limit the amount of work affected by changing priorities, requirements, or designs. This frees your team to respond quickly and abandon little. Second, WIP limits restrict the flow of work to match the pace of the slowest step (also known as the “constraint”). Because you can’t possibly complete work faster than your slowest step, pacing the other steps to match it yields the greatest efficiency and highest productivity.

You want to use the smallest WIP limits that still keep your team fully engaged in delivering value to customers.

• Start with setting the WIP limit for your slowest step to the number of team members doing that step, plus a 50 percent buffer. That always keeps the slowest step busy yet still limits the number of note cards at that step.
• Then use ratios to set the WIP limits for the other steps so that their throughput matches the slowest step.
• The result is starting values that you can continually adjust as needed to maximize throughput.

Here’s a worksheet with values from one team.For the team in this example:

A On average, each analyst can specify roughly six items per month, each developer can implement roughly two items per month, and each tester can validate roughly three items per month. (Since you’re using ratios here, you could use per week or per day if that’s easier.)
B Implementing was the slowest step (two items per month per person).
C The team had three developers implementing items from the backlog.
D The throughput was six items per month (2 * 3).
E Dividing that throughput by the average rates for each step gives you the people needed for each step to match six items per month (one analyst, three developers, and two testers).
F Adding 50 percent to those people totals and rounding up gives you each step’s WIP limit (2 for Specify, 5 for Implement, and 3 for Validate).

The WIP limits from the worksheet are fine starting values. The limits can be adjusted at any time to maximize team output and agility. It’s handy to write the WIP limits on your signboard next to each step, like this:

Notice how the WIP limit applies to the total number of active and done cards for each step, except for the last step, which has a limited number of active cards but an unlimited number of done cards. (When items are through validation, they are completely done and basically off the board.)

Step 4: Define done

Kanban regulates quality through a deceptively simple mechanism. Before a note card is moved from the left to the right column of a step, the work on that item must pass certain rules—your definition of “done” for that step (also known as the pull criteria). The use of two columns per step in Kanban may seem excessive, but it makes all the difference.

Items in a step’s Done column count toward that step’s WIP limit (except for the last step). Remember, you want to match throughput with the slowest step. Thus, if implementation is taking a long time, you could have two items in the Specify step’s Done column and not be allowed to specify any more work. That’s good. You shouldn’t overload implementation, and you should probably be helping to unblock implementation. More about that in this chapter’s “Troubleshooting” section.

Kanban distinguishes between finishing one step and starting the next. Of course, those are always two different things. However, signboards used for Scrum or other daily standup meetings typically move an item to the next step on the board as soon as it’s done, thus losing the important distinction between items ready for the next step and items actively in the next step.

Separating the completion of one step from the initiation of the next decouples the steps. This frees you to have rules that define what it means to be done with each step, regardless of what the next step happens to be.

With the steps decoupled, your team needs to define “done” for each step. I strongly recommend that you define this criteria together as a team, with everyone committing to follow the definitions. Here are examples from another of my Xbox teams (you might have noticed the rules at the bottom of their signboard shown earlier).

Specify done rule All items broken down into tasks that can be finished in less than a week each, and quick specs completed for each item.
Implement done rule Code is reviewed and unit tested, the static analysis is clean, the code is checked in, acceptance tests pass, and the customer-facing documentation is complete.

Validate done rule The work is deployed to production and tried by a significant subset of real customers. All issues found are resolved.
These rules come with a few best practices:

The first step, Specify in my example, often includes breaking down backlog items into similarly sized short tasks, each with its own new note card. (For example, visiting Disneyland could be broken into seeing Adventureland, Frontierland, Fantasyland, and Tomorrowland.) The WIP limit for the Specify step refers to the original backlog items. You can think of the smaller items as being grouped within that step. Upon leaving the step, the smaller items are considered separate (each short task counts toward the implementation WIP limit). This breakdown does impact throughput, so you may need to adjust your WIP limits over time (details in this chapter’s “Troubleshooting” section).
Before someone moves a note card from left to right in a step, a team member should check that the done rules are met. It’s these agreed-upon rules that drive quality upstream at every step and prevent lazy or careless team members from taking credit for incomplete work that responsible team members must finish and fix later. The rules work only when team members hold each other accountable for following them.
Posting the rules at the bottom of your signboard reminds team members to apply them and provides a central place to discuss the rules should the team decide to change them.

Step 5: Run your daily standup

Now that you’ve defined what being done means, your team is ready to use Kanban. With a loaded backlog, no planning meetings are necessary. There are no milestones, no sprints, and no retrospectives. Kanban flows continuously, so long as there is work to do. Naturally, you can still bring the team together at any time for design reviews, demos, customer reviews, and discussions about product and process improvements. However, the only meetings Kanban typically has are daily standup meetings at the team signboard. Any team member can run the daily standup. My teams’ project managers usually do this because it helps them update Xbox online tracking tools. The one required agenda item is asking whether any team members are blocked or otherwise need assistance, then assigning people (often the project manager) to resolve the issues. Experienced teams can complete the standup in five minutes.

My teams also like to use the daily standup to learn what other members are doing and to celebrate the progress they are making together. This makes the meetings a little longer, but it builds a shared sense of pride and ownership. For an example of a standup, I’ll pretend that the team moves note cards only during the standup (not the most efficient process, but easiest to explain). In reality, any team member moves any card at any time, so long as the move doesn’t exceed WIP limits and the done rule is met. Also in reality, my teams are a mix of men and women, but I’ll stick to male pronouns by default.

At the start, let’s say the signboard looks like this:
There are seven planned items in the backlog. One item is being specified, and one item is done being specified (having been broken down into four smaller items, shown together on the same row). Three items are actively being implemented, and two items are done and ready to be validated. Finally, three items are actively being validated. There are likely a pile of note cards that are done with validation (the last step), but they don’t count toward the last step’s WIP limit. (One of my Xbox teams used completed cards to wallpaper a team member’s office to surprise him when he returned from vacation.)

At the beginning of the daily standup, the project manager starts at the last step, opening up slots when items are done, and works his way to the left. (Because of WIP limits, items can move to the right only if there’s room. Pulling cards from the left to the right is what makes Kanban a “pull” system.)
The project manager points to the last step, Validate, and asks, “Any items done being validated?” Team members say two items are done. Other team members check the Validate done rule with questions such as, “How many customers were involved?” When the team is satisfied, team members happily move the two items to the final Done column —more value delivered to customers!
Because items that are completely done don’t count toward the final step’s WIP limit, there’s room to validate two more items. Team members pull two cards from the Implement step’s Done column, decide who will do which work item, and then write their names on the cards they’ve selected.

Key point
Work item assignments are made “just in time.” This avoids blocking an item because a previously assigned team member is busy at the time the task is ready. (This chapter’s “Troubleshooting” section has more details.) Next the project manager asks whether any implementation items are finished. A team member says that one item is done, and another team members says, “That’s right, I did the code review, checked the unit tests and static analysis, and the customer-facing documentation looks good. It’s all submitted.” A team member moves the completed item to the right side of the Implement step.
Two slots are still available for Implement (because two items moved to Validate), so team members pull the top two items from the Specify step’s Done column, decide who will do which work item, and then write their names on the cards they’ve selected. Now the project manager asks the analyst whether he’s finished specifying the one active item he has. The analyst thanks team members for their feedback on the quick spec and says the item broke down into three smaller tasks that will each take just a few days. The analyst adds three new cards (for the broken-down tasks, shown together on the same row).
The analyst doesn’t pull another item from the top of the backlog because the Specify step has reached its WIP limit (two items, each of which has been broken down into tasks awaiting implementation).
The project manager asks whether anyone wants to change the order of the backlog based on new requests or requirements. A short discussion ensues, a new item is added, and two items swap places. Finally, the project manager asks whether anyone needs extra help. (Remember, this is the only required question at daily standup. Everything else I’ve described is done by any team member at any time.) The project manager focuses particularly on implementation because the analyst is blocked until a couple of more items have completed the Implement step. One of the team members mentions a few things that need to be sorted out, and the analyst offers to help.
The daily standup is over, and everyone returns to work. The whole process takes less than 15 minutes. The project manager stays behind to enter the status changes of items into the organization’s tracking tools and then starts sorting out the issues raised during standup.

Troubleshooting

The daily standup example went smoothly, with only one hitch (needing to help the implementation effort because no more items could be specified). However, all kinds of things can happen, raising many questions. This section covers a wide variety of common issues. I’ll start with the one from the example, “What happens when an intermediate step reaches its WIP limit and all items are done?”
Problem: Blocked because all items in an intermediate step are done In the example, the analyst was blocked because his step, Specify, had a WIP limit of two, he had completed two items, but the Implement step wasn’t ready to take them yet. Here’s the signboard:
The same thing can happen with any step but the last one (which has an unlimited Done column). What should the analyst do?
He could specify the next item from the backlog, but doing that isn’t helpful; it just creates more work for the team to implement, and the team is already at its implementation limit. The team can’t go any faster without help. Yes, the next item in the backlog may eventually need to be specified, but that only hides this issue until later, doesn’t help solve the problem, and may even result in work being thrown away if priorities change.

The best thing for the analyst to do is to help with implementation (the next step). He could implement some items himself. He could help with design or implementation issues. He could do some research or work with partner teams that might make implementation faster.
If there’s no way for the analyst to help with implementation, he can still be productive by getting a head start on customer research, advanced planning, or new tooling. There’s always productive work available that doesn’t hurt the team. Problem: Blocked because prior step has no items done Let’s say your signboard looks like this:

The Validate step is ready for a new item (the last step’s Done column doesn’t count toward its WIP limit). However, the Implement step has no items that are done. The testers doing the Validate step are blocked. What should they do?

Just as when the analyst was blocked, the best thing for the testers to do is to help with implementation (the prior step). They could implement some items, help with design or implementation issues, or work with partner teams to make implementation faster. They could even grab lunch for the development team—whatever is needed.

If there’s no way for the testers to help with implementation, they can still be productive by analyzing bugs or usage patterns, running experiments, or improving tooling. There’s always productive work available that doesn’t hurt the team.

Problem: Step taking longer than usual for an item While different steps require different amounts of time and effort, each step should ideally
take about the same amount of time for each item. That’s why the first step often breaks down large items to smaller items of similar size. However, there’s always variation, and sometimes one step might take unusually long for a particular item.
If a step for an item seems to be taking a long time, team members should review what’s happening.
Perhaps the person assigned to the item is blocked or needs help.
Perhaps the item should be broken down further into smaller items.
Perhaps more design work is needed.
Perhaps the person assigned to the item is expanding the scope of the item inappropriately.
Perhaps there are some substantial unresolved bugs.
Regardless of the cause, items should always be moving along at a fairly regular pace.
Whatever the problem is, the team should address it quickly. I go into more detail about some specific situations later in this section.
Problem: Constantly getting blocked If team members or work items often seem to be blocked, your team may need to adjust the Specify step, WIP limits, staff assignments, or other variables. The proper action to take depends on the symptoms.
If the flow through your steps is uneven because items vary substantially in size, be sure that your first step (typically Specify or Breakdown) breaks down items into similarly sized tasks. Team members can review the item breakdown to ensure a reasonably consistent result.
If a step still sways from having plenty of work to no work and back again, increase the step’s WIP limit by one (extra buffer to handle the variation). If a step is slow, and the steps before and after are constantly blocked, you’ve got a few choices:

Do a root-cause analysis of why the step is so slow, and then speed it up. That could mean assigning more people to the slow step, improving the tools or specs, giving folks faster computers, or whatever helps fix the problem. Reduce the WIP limits by one for the steps before and after the slow step. Doing this also frees up time for some team members, who should be assigned to the slow step or to other projects. (The minimum WIP limit is one.)
If team members assigned to the slow step are idle much of the time, increase the WIP limit of the slow step by one. However, be certain that’s the real problem—increasing WIP limits should be a last resort. If a step is fast and always seems to have a full Done column, reduce the step’s WIP limit by one. (The minimum WIP limit is one.) The team members assigned to the fast step should then have additional time to do productive work on other projects.

Problem: Item blocked awaiting external input Items often get blocked midstream awaiting external review, dependencies, questions, approvals, or other input from outside the team. For my Xbox teams, this happens most often at the Implement step.
To handle the issue, we add a Track column to the middle of the Implement step. Items are moved to the Track column whenever they are blocked awaiting external input. Tracked items don’t count toward the Implement WIP limit. We talk about their status during every daily standup until they are unblocked. When a tracked item is unblocked, it moves back to the Active column as soon as a slot becomes available. The logic is that any item already in Implement has higher priority than the next item from Specify. (I talk about other ways to handle late or unstable dependencies in Chapter 7,
“Using Kanban within large organizations.”)
Occasionally, it becomes apparent that an item will be blocked indefinitely. We have a special area for those items in the corner of the signboard. We call it the “parking lot.” Every few weeks, we check on the status of parking lot items, but we don’t do this daily. Problem: Bugs impacting team Software development is prone to defects, even with strong done rules in place. Usually, dealing with operational issues (tickets) or ordinary bugs is a regular part of doing business, like email or other daily overhead. The effort required is already factored into
the average work rates used to determine WIP limits and doesn’t need to be tracked on the signboard (assuming you already have online systems for tracking bugs and tickets).
However, sometimes fixing a particular bug or an operational issue is as much work as other product improvements. These tricky issues are managed like any other work item. You create a note card, order it against the rest of the backlog, and slot it into its proper place. These complex issues typically need to be specified, implemented, and verified like any other product work.
Note
If all your team does is fix bugs or handle tickets, Kanban can be an excellent way to manage your bug or ticket backlog efficiently. In that case, every note card is a bug or ticket, and the steps are the ones used to resolve those items. For more details, see Chapter 8, “Sustained engineering.”
Problem: Item needs design work Sometimes an item in the backlog is so complex that an analyst needs extra time to specify it and break it down. Often this involves some user experience design, architectural design, and perhaps experimental design. (My favorite approach to design work is called Scenario-Focused Engineering. The design work is a task unto itself, so you make the design work a separate work item on the
signboard.

The Specify step for design work is breaking down the work into smaller tasks. The Implement step for those tasks is creating the design. The Validate step for those tasks is reviewing the design and getting it signed off. When it’s done, you’ve got a completed design, which then adds several new items to the backlog.

Yes, approaching design work as though it were product work is a bit of a stretch. Ideally, you’d use a separate signboard with steps specific to design work. You should do this if a separate team is assigned to design or if you want to use a separate swim lane for design work. However, using the same signboard for occasional design work does function quite well in practice, and we are Kanban
pragmatists. We’re trying to deliver value to our customers in the most efficient manner and with the highest quality possible. If that means altering the done rules occasionally to fit design work instead of product work, so be it.
Problem: Important review, demo, or conference approaching Sometimes, major work has to get done that isn’t design work or product work—it’s preparing for an executive review, fashioning a demo for customers, authoring a conference presentation, or some other significant task. How do you account for this time on your signboard? The same way you account for design work—add a note card to the backlog. Be flexible. Define special done rules to suit the current work. And then deliver the work on time with high quality. Don’t worry; the imaginary Kanban police won’t mind.

Problem: New work, plan changes, and updated requirements New work can arrive at any time, plans can change, and requirements can be updated. When change happens, do the following:
Write note cards for new items. Reorder the backlog to account for changes in priorities or to slot in new items. Leave items already in work alone, except to edit them if their requirements have changed. Even though priorities may have changed, there’s usually no reason to abandon work in progress. Newly prioritized work will move into the flow in less than a week. That’s because work in progress is limited, so waiting time is short. In the rare event that new work must commence immediately, you can move active cards to a Track column and free up space for the new items.

Note
No special planning meetings are necessary to account for new work, plan changes, or updated requirements.
Problem: Item needs to be assigned to a busy team member Sometimes work items are uniquely suited to a particular team member because of that person’s expertise or past experience. If that team member is busy with another item or otherwise unavailable, you’ve got a few choices:
Assign the item to another person and have the preferred team member provide review and oversight. This is a great option for spreading knowledge across your team and backing up the preferred team member. (You never want one person to be a bottleneck.)
Reassign the preferred team member’s current work to another person.
Move the card to the Track column until the preferred team member is available.
Lower the order of the item in the backlog.
Problem: Some team members like doing more than one item at a time
When you limit work in progress to one item per team member, plus a 50 percent buffer, people are basically assigned only one work item at a time. Working on one item at a time avoids costly context switches and truly focuses your attention. There’s always email or other minor work to do if you’re ever stuck. However, some people work best with clumps of related work. It’s not ideal from the perspective of minimizing work in progress, but accommodating different work styles is important to a cohesive team. If your team has such a person, increase the WIP limit for this person’s step by one or two (giving him 2–3 items at once). It’s not ideal, and should be used only when the person’s productivity is clearly negatively impacted by the lower WIP limit.
Problem: Can’t find time to improve tools and automation
Customers, partners, and management can be demanding. With these demands, it’s hard to find time to improve your own team’s tools and automation. However, it’s those infrastructure improvements that enable you to deliver more work in less time and at higher quality (just like with Kanban).
The solution is to put tool and automation improvements on note cards, just as you do for product improvements, and order them in your backlog accordingly. One or 2 items in 10 should be infrastructure improvements—after all, there’s always room for improvement.
Problem: New person joins the team
When a new person joins the team, WIP limits may need to be adjusted. Ideally, that person is assigned to the slowest step (increasing its throughput). If so, simply work through the process described in “Step 3: Set limits on chaos” again. If the new person is assigned to a different step, she is going to have free time or her peers will. That time can be used wisely by helping with other projects. Remember, you can’t go faster than your slowest step.
Problem: Team has long design discussions during standup
Daily standup meetings should take 5–15 minutes. Sometimes teams get into design discussions as they address new items or handle blocking issues. A brief overview is fine, but long discussions should take place at a different time. Some of my teams schedule a
conference room for an hour after their daily standup for design discussions. They don’t use it every day, but it’s there when they need it.
Problem: Some team members can’t attend standup Sometimes team members can’t attend the daily standup meeting. Perhaps they are
working from home that day or are on a trip. Team members can ask other team members to move note cards for them at any time. They can also send their status to the project manager, attend standup via telecommunications, or use an online meeting.
If you have team members spread across significant distances, you’ll need to use a virtual signboard and have online standup meetings.
Problem: Team focusing too much on process details Some team members may be quite passionate about process. In their effort to be pure, do things “the right way,” or simply comply with what they see as “hard rules,” team members can focus too much on process details in place of delivering high-quality value to customers. Those team members may think that following rules and practices precisely is necessary to deliver high-quality value to customers.

Following the rules and guidelines in this book is important to a team just starting with Kanban. However, over time your team will internalize visualizing its work and limiting work in progress. Team members will naturally swarm to blocked steps and avoid working on too much at once. At that point, being flexible is an important part of being efficient.

You don’t want to compromise on quality, but you should trust your team to operate in the manner that best suits its makeup and current needs. If you find that quality or efficiency has dropped significantly, you can always return to a stricter approach.

Checklist
Here’s a checklist of actions to quickly start using Kanban:
Capture your team’s high-level routine as a series of steps.
If you are unsure, start with the steps Specify, Implement, and Validate.
Redecorate your wall with a Kanban board that has a Backlog column and two columns for each of your steps.
Set limits on chaos that restrict the maximum number of work items (cards) for each step. These are known as work-in-progress (WIP) limits.
Define done rules for each step that must be met before a work item (card) can be moved from the Active to the Done column for that step.
Run your daily standup at a set time each day, focusing on issues that block work from progressing (cards from moving between columns).
As needed, update your organization’s tracking system with your team’s current status.
As needed, adjust your WIP limits and done rules to ensure quality work that flows smoothly through your signboard.
As needed, add a Track column between the Active and Done columns of your implementation step to track external input that is blocking implementation of a work item (such as a late or an unstable dependency).
As needed, add new items (cards) and reorder items in your backlog.

From Agile Project Management with Kanban