Sample Kanban Workflows for Non-tech Teams

In a previous post, we discussed why Kanban offers a simple, flexible, and highly-effective methodology for non-tech business teams who want to adopt more Agile ways of working. In this article, we’re providing three examples of how three teams — Marketing, HR, and Finance — might set up their Kanban workflows to accomplish their tasks.

Don’t take these as “best practice” workflow recommendations. Part of the beauty of Kanban is how customizable it is. As you review these examples, think about your own team’s current workflow and required processes. Based on the concepts outlined here, you should be able to develop a Kanban workflow that best supports the work you do. And, as you begin using the system, you’ll no doubt find ways to fine-tune it to continually improve.

Keys for Agile business teams using Kanban

As highlighted in the previous post, keep these three points in mind to ensure the Kanban system is more than just a highly organized To Do list. For Kanban to be Agile:

1. There must be a mechanism in place to groom and prioritize items in the backlog so that every time a new item is pulled into the system, it’s the right thing for the team to be working on at that time.
2. The goal should be to align the team’s Agile processes with other teams in the organization, effectively “joining the value stream” wherever possible.
3. If there is no mechanism in place to routinely review the system itself as well as the quality of the output it produces, one of the most valuable benefits of Agility can be lost.

With those points in mind, let’s look at the Kanban workflow examples.

Sample Kanban workflow for content production on the Marketing team

The first example is for a content team in the Marketing department. To keep it simple, we’ll assume this team concentrates strictly on text-based content like blog posts and white papers. The flow includes the following steps:

1. To Do
2. Researching
3. Writing
4. Reviewing
5. Publishing
6. Promoting
7. Done

Each content piece that runs through this workflow is an Epic, and each step in the workflow will have its associated tasks (or Stories) that need to be complete before the Epic can move to the next step.

WIP limits

The team is small — a manager, a writer, a project coordinator, and a social media specialist.

• The manager handles developing the content epics and stories, and grooming the backlog to prioritize the most important items at any given time. (In Agile terminology, the manager is handling aspects of the Product Owner and Product Manager roles. In larger organizations, they may have a superior who serves as Product Owner.)
• The writer handles research and writing for each piece.
• Any of the other three team members can help with reviewing the completed draft.
• Then, the project coordinator is in charge of publishing, and the social media specialist promotes the published piece.

To avoid costly context switching, the writer isn’t going to research or write more than one piece at a time. On the other hand, up to three people at once can handle the review process if necessary. Only one person can publish a given piece. But, the social media promotion extends over weeks as different channels engage, so there’s no reason that team member can’t maintain many pieces at once. Over time, she’s determined that eight is a comfortable number of content pieces to actively promote simultaneously.

The makeup of the team makes the following WIP limits reasonable:

1. To Do
2. Researching – 1
3. Writing – 1
4. Reviewing – 3
5. Publishing – 1
6. Promoting – 8
7. Done

Policies

To ensure the system runs smoothly, the following policies govern the workflow:

1. To Do – All epics must meet an agreed-upon “definition of ready” before prioritization in the backlog. (This ensures that an item doesn’t get hung up in the system because it can’t be researched and written yet. If accomplishing this requires a lot of bandwidth, the manager may have other team members assist in preparatory tasks, and perhaps add a new column for Preparation, with a WIP limit of 4.)
2. Researching – N/A (Since every piece is different, there are no specified policies here. The piece moves on to Writing once the necessary research is complete.)
3. Writing – All epics must meet an agreed-upon “definition of done” before they move to Reviewing. (This ensures that a finished draft meets the intended purpose. It may still come back from Reviewing with suggested edits, but those edits should not be fundamental.)
4. Reviewing – The epic must meet the “definition of done”, and be free of errors before moving to Publishing. (This step focuses the process on quality before “deploying” to the customer. if the Reviewing status requires an additional review or approval, the team may decide to create a new column after Reviewing that accounts for that, removing it from Reviewing WIP. Then they can bring another item into Reviewing.)
5. Publishing – N/A (The epic will move to Promoting after publishing.)
6. Promoting – N/A (The epic will move to Done once the promotion is complete.)
7. Done

As this process scales, it will be necessary to account for dependencies. For example, the Researching step may require interviewing sources, which means potential scheduling issues. A new column for Interviewing with no WIP limit can ensure other pieces continue to move through the process. Or, the content team may need a separate design team to produce layouts or images for a given piece. A Design column could be added between Reviewing and Publishing, with a WIP limit based on the design team’s capacity. Then, when work is complete and reviewed by the design team, it can move on to Publishing.

Sample Kanban workflow for hiring and onboarding on the HR team

The second example is the hiring and onboarding process in the HR department. The flow includes the following steps:

1. Prospects
2. Applicants
3. Interviewing
4. Hiring
5. Onboarding
6. Done

In this case, each Epic is a job candidate, so the HR team must complete associated Stories before the individual can move to the next step in the hiring process. This workflow is unique in that there are two backlogs — Prospects and Applicants — because potential candidates may be actively pursued by a hiring manager (Prospect) or may submit an application on their own accord.

WIP limits

Again, this team is small — a manager, and two hiring specialists.

• The manager coordinates the process and grooms both backlogs to prioritize the most qualified candidates based on the roles needed.
• The HR specialists take over, starting with the Interviewing step.
• Either specialist can handle any step going forward.

You don’t need to limit the Prospects or Applicants backlog because they want to continually collect potential employees to consider. But, there are only two specialists to handle interviewing and hiring tasks, both of which should be completed as quickly as possible. Onboarding is a longer process that involves representatives from several departments, with the HR specialists serving as coordinators, which allows them to handle many employees at a time. So, the makeup of the team makes the following WIP limits reasonable:

1. Prospects – N/A
2. Applicants – N/A
3. Interviewing – 2
4. Hiring – 2
5. Onboarding – N/A
6. Done

Policies

To ensure the system runs smoothly, the following policies govern the workflow:

1. Prospects – All prospects must meet a basic “definition of ready” before they are prioritized in the backlog. (This is based on the minimum requirements for the particular role(s) the individual is being considered for. It’s understood that knowledge of a prospect’s skills and experience may be incomplete.)
2. Applicants – Prioritized Prospects take precedence over prioritized Applicants unless otherwise determined by the manager. All applicants must meet a basic “definition of ready” before they are prioritized in the backlog. (Since the company is actively seeking out Prospects, it makes sense to move them to the top of the line when they submit their official application. Of course, if an Applicant’s skills and history show them to be a better fit for the role, that policy can be overridden.)
3. Interviewing – An interviewee must be approved by (names or roles of those responsible for interviewing) before moving to Hiring. (In some organizations where the interviewing process is lengthy, the team would likely add additional columns for Interview 2, Interview 3, etc., each with a WIP of 1.)
4. Hiring – N/A (The hiring process itself is purely mechanical and is complete when the paperwork is signed.)
5. Onboarding – All applicants must meet the “definition of done” before they are moved to Done. (New hires will only be considered onboarded when the full agreed-upon list of onboarding activities is completed.)
6. Done

During the Applicants step, the individual’s application may show they are not as qualified for the role as first assumed. In that case, the manager would decide if they should be de-prioritized in the list to be considered for roles in the future, or removed from the backlog entirely. Likewise, at any point during the Interviewing process, the company or applicant may decide to not move forward. The manager will make the same determination then.

Again, these are just examples that may not fit your organization’s unique needs. Learn more with our webinar-on-demand, How to Align Non-technical Teams with Jira and Wrike.