# Kanban at MidFirst

# 1. Backlog items created and refined

The product backlog is a collection of well-defined user stories, tasks, and other units of work that represent distinct milestones, features, and other deliverables required to complete the project.

The product owner is responsible for the creation of user stories that populate the product backlog, while developers are responsible for the creation of tasks, if any, that represent individually deliverable aspects of those stories.

User story documentation

In Kanban, the product backlog is a living document, it is constantly prioritized and refined as in-process work items are completed. Kanban typically prescribes no regular cadence or formal meetings specifically dedicated to backlog refinement. This does not, however, mean that tickets in the product backlog are not refined. It is up to the team to find what works for them and ensure that work is well-defined and understood before beginning work on backlog tasks. This work may be accomplished in regular, dedicated refinement meetings, scheduled as need arises, or performed ad-hoc in other product meetings.

Some teams may elect to have multiple swim lanes (columns) within the backlog that make a distinction between work that still needs refinement and work that is ready to be started.

# 2. Tasks are worked

Once there are a sufficient number of refined tasks in the backlog the team can begin their work. Tasks are moved from backlog or to-do to in-progress as work begins and to complete, done, or other swim lanes as they are completed, stalled, or other.

Kanban emphasizes continuous flow. As such there are oftentimes no clear boundaries that provide a natural opportunity to create releases, seek feedback from stakeholders or end users, refine newly added backlog tasks, or refine the Kanban process itself. Frequently, there is a need to inject a break of some kind in order to address one of these needs.

Creating releases:

A focus on epics or other milestones can help to find a natural point at which to create an official release. The team should work with product on which milestones may represent good points at which to create releases and have them deployed to an environment for testing or production use by end users or stakeholders.

Receiving feedback:

Ideally, the testing environment should be deployed to continuously as tasks are worked and code is merged. In environments where this automation is not present, teams should create and deploy releases with a more frequent cadence. Testers, end users, or stakeholders should actively verify and give feedback on features either continually as they are released or at some other, preferably narrow, regular interval.

# Other considerations

# Swim lanes

Kanban board swim lanes help to keep active tasks visually separated from tasks that have not yet started as well as communicate additional state.

Common swim lanes include:

Name	Description
Backlog	Tasks that have been created but may not yet have been refined by the team
To Do	Tasks that have complete descriptions and acceptance criteria (AC), have been refined by the team, and are ready to begin work
Blocked	Tasks having some type of blocker that has stalled progress
In Progress	Tasks actively being worked on that have no blockers preventing progress
Code Review	Tasks awaiting code review
In QA	Tasks having their corresponding code merged and deployed to testing environment. This swim lane may be broken into components of its own
Done	Tasks that have been merged, tested, and verified

# Work in progress limits

In an ideal world, developers would never be working on more than one task at a time. However, when code review and manual testing processes are introduced to a workflow they also introduce some amount of idle time for developers while they wait for these stages to complete. While waiting on code review or testing feedback, developers should begin work on other tasks in order to maintain momentum and keep the project moving forward.

Developers should limit their in-progress work in order to minimize the overhead of keeping feature and fix branches

up to date with upstream changes such as release candidates.

We have found that 3 assigned tasks between the in-progress and done states is a reasonable number to maintain and that anything beyond 5 introduces wasteful amounts of overhead in keeping up to date with upstream changes and limiting context switching.

When this number is reached, developers should communicate this state to peers, testers, or managers so that it can be addressed as quickly as possible. !!!