“If you are together in a room, use sticky notes. If some of your team members are remote – use Cardsmith. Cardsmith is the closest experience to ‘sticky notes on a whiteboard’ as you can get.”
Kanban has moved beyond the manufacturing shop floor to become a popular visual productivity method for many types of teams in wide range of industries – from software, healthcare, law practices. Likewise, Scrum, which evolved from Lean for Agile software teams, is now used by groups from industrial design to market researchers.
The concepts of Kanban and Scrum go beyond board structure: they are about ways of working and behavior changes in and around the team, like stakeholders and senior management.
Shared Benefits of Kanban and Scrum Methodologies
The benefits of Kanban and Scrum methods are almost identical.
Both Kanban and Scrum promise to:
- Deliver value to the customer, faster.
- Build trusted teams that hold each other accountable.
- Visualize the work so everyone knows what is being worked on at the same time.
- Reduce waste, which is defined as work that never gets seen by the customer or that is not valued by the customer.
- Improve the quality of the work.
- Encourage management to see and unblock obstacles vs. micromanaging the team.
- Reduce stress amongst the team members.
It is possible to create a hybrid version of Kanban and Scrum which is sometimes referred to as Scrumban. In fact, there are many different versions of Scrumban that mix and match different elements of Scrum.
Because the two methods are so similar, you may not know at this point if you want to do Kanban, Scrum, or a hybrid of both. We have created a twelve step process to create your own visual project board.
In step #2, you’ll be asked to decide if you are doing Scrum, and if so, the process will differ just a bit from there. The major difference is how work is planned for, as Kanban does not integrate sprints.
Step #1: Create a bare bones, basic Kanban or Scrum board.
An important aspect of both Kanban and Scrum is visualizing the work. Because it is so easy to create board structures and then change them on the fly in Cardsmith, we will get started right away creating your visual board.
Both methodologies emphasize continually improving on the process. A tool like Cardsmith that can be so easily adjusted allows you to evolve your process with the team as you learn and evolve.
Enough said, let’s get started!
Create a new board, give it a name, and switch to Grid View.
Create the following four columns:
- Backlog
- Ready to Start
- In Progress
- Done
These are the basic columns for any Scrum or Kanban board.
You might wonder why we are suggesting a Ready to Start column in addition to the Backlog column.
In Kanban, all future work goes into the Backlog column. Only work that you’ve decided to move forward goes into the Ready to Start column. The Backlog column may or may not be sequenced in priority order, but the Ready to Start column will hold cards that are prioritized in order. This makes it so that when capacity becomes available, the team can simply pull the top card into the Doing or In Progress column.
Click to view and use a basic Kanban board template in Cardsmith.
Step #2: Decide if you are doing Kanban or Scrum.
Depending on your situation, you’ll be creating cards that represent anything from a task within a project to an entire project.
Kanban is great for any process-oriented team that follows a relatively standard process. These are some types of work units that I’ve seen on Scrumban or Kanban boards: Features, Bugs, Legal Documents, Month End Closes, Leads/Prospects, Business Partners, New Employees (requiring on-boarding), Locations (to be scouted), Blog Posts, Marketing Campaigns, Media Companies (as part of a PR campaign). The possibilities are endless!
Here lies the main difference: If the work is continuous, as typically is the case with small software features, speaking engagements, blog posts, etc., you will benefit from Kanban over Scrum.
For this type of work, each card typically adds value all on its own when it is completed. The photo package for the Bride and Groom was delivered, the advertisement was launched, the bug fix was released to production. Value was delivered.
If the project is complex with lots of tasks that need to be delivered together in order to realize value, and/or with multiple people involved with each part of the project, you will likely be better off with Scrum.
Scrum involves a more formal planning process called sprint planning, where multiple user stories are grouped together into a sprint that has a finite time period for completion.
Sprints are typically two to four weeks in time and when the Sprint time is over, the sprint ends. It may be delivered short, with a partial scope, or not at all, and deemed a failure. Either way, the sprint ends, a retrospective is held (see step #10), and the next sprint of the same timeframe is then planned and started.
Step #3: Add the User Stories column to your board (optional for Kanban).
Scrum introduces the idea of user stories.
In Scrum, you start with User Stories, which are like use cases, but written from the perspective of the customer.
A good user story describes:
- The type of user.
- What they want or need.
- Why they want or need it.
Here is an example of a user story for a software project:
“In order to collaborate with their team, project managers need to be able to share project plans with their team.”
Another user story may be:
“In order to contribute to a project plan, project contributors need to be able to comment on project plans and suggest changes to the project manager.”
User Stories are not only useful in software, but in other project work, or even in continuous improvement work.
Here’s an example of a User Story outside of software:
“In order to feel like they are valued customers, customers want to be on hold for no longer than thirty seconds when calling the customer support line.”
Here’s a real example from a marketing team’s Scrumban board:
“In order to keep our website on the top page of Google searches for our target market, we must continually complete projects that build and maintain our search engine optimization.”
This team is using Kanban because they are continually doing small tasks to improve their SEO, and achieving a continuous flow of work is best served by Kanban. The User Story exists as a way to remind them why their work is important.
Below is a visual board with the User Stories column added:
Click to view and use Cardsmith’s Scrumban template board
Even if you are not doing Scrum with Sprints, you may want to incorporate the idea of User Stories into your Kanban or Scrumban Board. A well written User Story aligns the team, helps prioritize future work, and serves as constant reminder of the overarching objectives.
Typically, you will see one User Story per row of a visual Kanban, Scrum or Scrumban board and all of the supporting tasks or project or units of work in the same row. These User Story cards typically don’t move through the board. They stay on the left most column titled User Stories, while the Blue Task Cards will move from the Backlog to Done columns as the work is completed.
Step #4: Decide what your rows will represent.
Perhaps you’ll create one row per User Story. But sometimes you may have a very large Kanban Board that represents a large program with a portfolio of projects. In that case, rows could represent different teams doing similar work. (see image under step #5 below).
Step #5: Add existing work cards to the board.
If you are doing Kanban or Scrumban, you will now add all the known work to your board. Create a card for everything that is in process or not yet started that you know you need to do (the Backlog).
This is important because the main goal of Kanban is to visualize all the work. It’s likely that you will have a number of projects or tasks in process at the same time.
Spoiler alert: this is something that you’ll be changing as you go through the process improvement part of implementing Kanban or Scrumban.
Click to use this template in Cardsmith.
Step #6: Add Process Step Columns to your board.
This section relates mostly to Kanban or Scrumban, but you can take some of these ideas into your Scrum Board as well.
If different types of resources are involved in the work, it is a good idea to subdivide the In Process column to represent the process step.
Below is an example of a Kanban board for Software where Analysis has been added (to occur before we go into Ready to Start because this is required to size the project and help with prioritization). We have also added Design, Testing, Review and Approve steps. These columns represent process steps that are lead by different disciplines (such as designers, programmers, QA engineers, and Managers).
If you do this after you’ve added the work cards to the board, you can move the cards into the correct process step column. Now you’ll have a much better visualization of where the work actually lies. You’ll see what step in the process is the bottleneck as it will have more cards within it. In our example below, Testing is the likely constraining resource for Team #1.
Step #7: Add Work In Progress (WIP) limits and Buffer columns.
This section relates more to Kanban than to Scrum, as Kanban is focused on the continuous flow of work through a process. Capacity needs to be managed to ensure competing process steps do not block the flow by becoming bottlenecks.
Based on our work above visualizing the Work In Process (WIP) for each process step, we want to implement WIP limits. Here, we set the highest number of cards allowed within the In Process column for a particular process step.
In our example, we set this to #2 for Development and #1 for Testing. This can be calculated based on gut feel, but is related to the size of the work and the capacity of the team to complete the work for that particular step.
In order to properly visualize WIP and manage WIP limits, we need a place to hold the cards that are completed by one process step. We do not want to “push” work into the subsequent process step that may not have the capacity yet to begin working on it.
We call these columns Buffer columns, and the words “Ready for…” can describe the current state.
In our example, once the programmers have completed the development steps, they can move the card into “Ready to Test,” placing it below other cards that may be in this column in order to maintain the flow and first-in-first-out concepts important to Kanban. Then, when the number of cards in the Testing column is less than the WIP limit for Testing, the test team can pull in the next highest card from the Ready to Test column.
Buffer columns now become the visual indicator of where work is blocked. As you can see in our example, Testing is still the likely constraint as the Ready for Testing column has the most cards.
Step #8: Implement a blocked work procedure.
At this point, you have visualized the work, minimized WIP, and brought your team together for daily or very frequent communications around the Visual Board. Whether you have a Kanban, a Scrum, or a Scrumban Board, you need to attack blockages of work quickly and effectively.
In Cardsmith, we like to color blocked cards RED and also give them the “!” icon so that it is easy to see at a glance which cards are blocked.
In both Kanban and Scrum, the team needs to be able to go to management and get help in removing blocking cards they cannot remove themselves. In fact, in Agile and Lean, this becomes management’s primary role. They no longer need to manage the team as the team is self-managing, self-improving and has all they need to complete the work.
But sometimes, work gets blocked due to factors outside the team’s control. A key resource is sick or leaves, or a policy or outside process is causing them a problem and someone from senior management can often step in and help resolve these resource or political issues.
In large-scale programs, it is a good idea to report on work blockages. What are the open blockages, how long were they active, and what type of root cause was in play?
A solid continuous project management program can review all of these questions and will systematically reduce the root causes to common issues.
Step #9: (Scrum only) Scrum Backlog Board.
If you decided in step #2 to do Scrum because you are working in a more complex project environment, you may have skipped a few steps by now…to find yourself here, at step #9.
From here, you will manage the capacity of the team by carefully planning Sprints. Before you can plan your first Sprint, you’ll want to capture all of the known work or objectives of the Project in User Stories on a separate board that is often called the Product Backlog Board. (It may also be a Program Backlog Board, or Project Backlog Board depending on your terminology.)
Whatever terminology you are using, this is where you’ll want to think of all of the things your program, or project or product will deliver over time. Write them in the form of User Stories (see Step 3 above for examples of User Stories). Then, add a Story Points field to your Cardsmith Card and estimate the size of the effort for each user story.
Story Points are useful as it is difficult to estimate the effort or time to complete something, but it is easier to estimate the relative difficulty or timeframe from one job to another. Over time, the team will get better and better at estimating the number of Story Points they can deliver in a single Sprint. We like to use a relative value for Story Points as follows: five for a large story, two for a medium story, and one for a small story.
Sometimes, multiple stories are grouped together into Epics. Epics are very large chunks of work that often require multiple Sprints to accomplish. Examples may be a new major release in Software or a new product line or brand in a consumer products company. If this applies to your environment, you may want to add a row for each Epic planned and place Story Cards into Epic row.
One of the first things the product owner, program manager, or customer must do is prioritize and scope the Sprint. Story Points can be used as a measure. We estimate that our team can deliver on six to seven story points in the two week Sprint.
Click to view and use Cardsmith’s template Product Backlog Board.
Cardsmith Pro-tip: Once you have added fields to User Story cards, use the “Set Default Card” option so the fields are added to new cards added to that board. You can then turn on Grid Totals for this Board in the Board Menu to be able to view the total Story Points.
Step #10: Create the Current Sprint Board.
At this point, you can copy, or move the User Story cards from the Next Sprint Row of your Backlog Board created in step #9 to the Scrum Board that you created in step #2. You might choose to rename the Scrum Board ‘Current Sprint’ or something similar.
You may find it useful to use the Freeform Board view of the Sprint board and break each User Story down into tasks or subtasks as shown in the picture below:
Once you have each User Story broken down into tasks, you’ll want to switch back to the Grid View, and move the User Story and Task cards into the Backlog column of your Scrum Board.
See below for what this may look like in our simple example.
Click here to view the Cardsmith Current Sprint Scrum Board.
Cardsmith Pro-tip: When you change board views, cards that were added to another view will be in the “Hidden Cards” area at the bottom on your board. Once positioned on a Freeform or Grid View, cards remain on that View. So you can always go back and forth between the Scrum Board Grid and the Work breakdown view of your current sprint board.
Step #11: Create a Retrospective Board.
Retrospectives are a formal part of the Scrum process. They are to be done at the close of one sprint before the team begins the next sprint.
Kanban does not have a predetermined retrospective period. However, Kanban is a lean tool and is closely related to continuous improvement. Therefore, building in retrospectives where the process itself is examined is good Lean practice. Here, Kanban can borrow from Scrum the typical outline of the retrospective process.
A retrospective typically consists of asking the team to brainstorm answers to the following four questions:
- What went well?
- What could have gone better?
- What do we want to try next?
- What questions do we have?
Once the team brainstorms and records answers to the above questions, they can be prioritized, grouped, and discussed. Changes to the way the team works together or how they interact with management or their customer can then be decided and implemented as part of the next sprint.
The retrospective is also a time to celebrate the closing of the last sprint as a team accomplishment. It’s a great time to come together in a positive way to build trust and rapport amongst the team members.
The retrospective is an opportunity to review the team’s accuracy in meeting the last sprint’s goals. Were all User Stories completed? If not, what did we learn? Do we need to change something to get better at estimating Story Points? Can we challenge ourselves to complete more Story Points next Sprint?
Click to view and use the Cardsmith retrospective template board.
Step #12 and beyond: Continually improve your process and evolve your board and the behaviors related to it.
Here are some tips and pitfalls to avoid.
Who can add cards to the board, and when?
In Scrum, the work is scoped during the sprint planning session, and until the Sprint is completed, work cannot be added to the board. You may want to have another board in Cardsmith to hold the Product Backlog–work that will be completed in future sprints, but not the current sprint.
In Kanban, you can add work (cards) at any time, but you cannot add cards to the “In Progress” columns. Work can only be added to the Backlog columns.
One of the key disciplines with Kanban is that once something is being worked on, you should not stop or lower the priority of the work with new work. Only when capacity is freed up by the work team should new work be pulled into work in progress columns.
You are free to re-prioritize cards at any time before they are moved into the In Progress, Doing, or other columns indicating work has begun. Keeping the amount of work In Progress as small as possible allows for maximum agility in the process.
WIP Limits, or how capacity is managed:
In Scrum, the capacity of the team is managed by not overloading the team with too much work for a given sprint. Typically, work is measured in the form of Story Points. Complex tasks get five points, medium tasks get two points, and easy tasks get one point. Over time, the team learns how many Story Points they can handle during a Sprint period, and they can challenge themselves to increase the number of points they can accomplish during a Sprint.
In Kanban, it is important to have a WIP limit on key columns. Over time the team should learn the right number of cards for the work in process column that most constrains the team. What do we mean by this? Let’s say your board has the following columns: Backlog, Ready to Start, In Design, Programming, and Testing.
And, for this example, let’s assume that programming is the resource that is most constrained. In this case, you can apply a WIP limit to the number of cards that we have at any one time in Programming. Three is a good number to start with and then you can increase or decrease depending on your team. The key here is to avoid assigning so much work that the programmers are tempted to multi-task.
Firefighting:
In pure Scrum, there are no fires to fight, as all work is preplanned and the team is fully dedicated to the sprint work itself.
In Kanban, you may see a ‘Fast Lane’ row on the board where urgent items can be dealt with. With most teams that we’ve seen, not all work can be planned, and the team often has to deal with unforeseen emergencies.
One of the most common hybrid approaches to Kanban and Scrum (sometimes called Scrumban) is the addition of this Fast Lane row.
However you do it, if you allow an Urgent row on your board, make sure you allow enough capacity to deal with the unforeseen emergencies. For example, in a software team, you may need to plan for fewer story points to handle bug fixing if the same team is responsible for fixing bugs on past releases.