As Agile/Scrum practices have continued to explode across the business world, Kanban (/kahn-bahn) boards have equally grown in popularity, especially via the introduction of tools which make it easier to use and collaborate on as a team digitally. What’s important to remember is that Agile and Kanban boards might not be applicable for all project-related use cases, and if introduced without proper context and established intended usage, implementing Agile practices or a Kanban board within your team might actually hurt productivity rather than help it. This Trexin Insight Paper will help establish Kanban board basic set up, how it fits into Agile/Scrum, and what you need to remember prior to implementing one on your own project.

THE BASICS

A Kanban board is an Agile project management tool designed to help comprehensively visualize work, limit work-in-progress tasks, and maximize efficiency (or flow) for a team. It employs cards, columns, and a focus towards continuous iteration to help technology and service teams commit to an appropriate amount of work per a defined period.

Each card (a “story” or “user story”) placed on a Kanban board represents one task within a larger body of work to be completed (which is generally called an “epic”). As a team thinks and plans for work to be completed at the beginning of an agreed-upon defined period of work (a “sprint”), a team will agree upon how many cards can/should be completed by the end of the sprint. Daily progress towards the work happening in each sprint (visualized and moved across the columns on a Kanban board) is then discussed during end/beginning of day stand-ups.

HOW KANBAN FITS INTO AGILE/SCRUM

It is important to remember that Agile is simply a concept to follow about iterative work and Scrum, its most synonymous term, is a loosely scripted process framework to follow to achieve that iteration. Scrum focuses individuals and teams on empiricism, which essentially means that the only way to truly learn something and make progress on overall goals is to do/try over a defined period, and then take time to reflect on what you learned so you can get better and improve for the next round.

The most common method to achieve this empiricism via Scrum are the usage of cards and a Kanban board to visually track progress across the team. There are a host of tools which help accomplish this in the digital age today (JIRA, Rally, Pivotal, Planner, Excel, etc.).

KANBAN BOARD SET-UP AND PRIMARY USE CASES

While a board can be set up in many ways to meet a team’s specific visual tracking needs, there are typically a few consistent columns:

• Product Backlog or Icebox: A backlog typically consistent of all tasks (cards, stories, etc.) which make up a larger body of work (an epic). This should not contain a complete list of everything under the sun, but rather a good group of the main tasks to be worked on:
  • It’s recommended to keep a backlog/icebox to 10-15 items max. This keeps the focus without a team thinking too far ahead (the exercise of whether to pull items into a spring backlog or leave it in an icebox can be called backlog grooming).
  • A note: if you think of a task to do but do not want to forget about it, this could be a great place to store it
• Sprint Backlog or This Week/Not Started: The agreed-upon work to be achieved for the agreed-upon length of the sprint – pulled from the product backlog. As tasks are worked on and completed during the week, they should get moved across the Kanban columns below.
• In Progress: As tasks get picked up to be worked, they are pulled from the Sprint Backlog and should be moved into this column. These are the activities which get the focus during the standup to ensure progress is being maintained and whether there are blockers which could require solutioning in offline conversations
• Testing or Review: As in-progress tasks are completed, they are moved to the review phase for more serious evaluation/finalization activities (QA, testing, leadership review, etc.)
• Complete: As tasks are fully complete, they are moved to this bucket/column; these items are also then reviewed during sprint reviews (to review overall progress on the work at hand) and sprint retros (focused on fixing/improving Scrum process for the team for the next go round)

CARD WRITING/CARD MANAGEMENT

• Cards can be called tasks, stories, or even simply ‘product backlog items’; whatever works for your team. The point of a card is to represent an unfinished task, an unsolved problem, or an unmet need which could be picked up in a sprint to help complete a larger body of work (epic).
• Cards should be written succinctly. They should not describe a ‘how’ and they should not be paragraphs in length. An action verb and a few nouns – at a glance, it should be clear what work is to be done and what will be completed.
• Cards really should not even have due dates as if it is decided to be picked up in the sprint (post grooming activities), it should be completed within that sprint. And if it is too big to fit within a sprint, then it needs to be broken out into smaller cards so that it can be.
• Each member of the team should manage their own cards and be prepared to speak to their progress in daily stand-ups. No other person should own your card, except for you.

DAILY STAND-UPS/DAILY SCRUMS

Daily, you/your team should be reviewing progress towards the work being completed in a particular sprint. It is not a time to report status (I did X today, and will do Y tomorrow, etc.), but rather focus on the outcome of work being delivered and if someone is truly stuck on their tasks (the reason for asking about blockers in the first place).

Designated Scrum Masters should ask individuals about progress towards card completion and individuals should be comfortable enough to share updates which could impact and help the team on their completion of their tasks too. As a reminder, you are iteratively building and working as a team. Share what is necessary to help everyone deliver quality work on time.

CLOSING THOUGHTS

Kanban boards are a great vehicle for operational daily work tracking in an Agile (iterative) fashion but are not built to provide an easy way to take a step back and examine the larger picture of the work being accomplished. If you do choose to implement a Kanban board on your team, just note that it will require care; you will likely need to augment it with a larger project/epic view which will give the team the comprehensive picture they’ll require to see the landscape and then be able to properly drill down within a given sprint. And every few months, plan to tear down and re-build to make sure the team’s needs are being met to keep productivity at its most optimal.

Be cognizant of the work you are trying to accomplish! Perhaps the team and project delivery are not suited to a Kanban board, and that is okay. While the above will help you get started if you do choose to implement one, there are a variety of tools and methods to achieve work delivery together – experiment and find one which works best with your team. Communicate, implement, and evaluate to improve – those are core Scrum techniques which everyone can appreciate.

If you find yourself in need of assistance to set up a Kanban board for your organization, project team, or even yourself, do not hesitate to contact Trexin for recommendations, guidance, and best practices. We would be thrilled to help.

Contact Us