Kanban

Overview

Kanban is a popular IT project management methodology focused on managing “Work-In-Progress” or WIP. The concept is that the only thing holding you back is the part of the process that takes the longest to complete.

In the TSD divsion, we provide guidance on Kanban in the form of approved Kanban Models. Each model consists of various states, swimlanes and exit criteria. We do this to help teams pick a model that fits for them, as well as provide support for measuring success of the models.

States vs. Swimlanes

  State 1 State 2 State 3 State 4 State 5
Swimlane 1 US2345
US3456




US0954



US6543
US0943


US94310





US23476
Swimlane 2   US3456
US6543


US94310
 

The Kanban board consists of 2 major components; States and Swimlanes.

States

States refer to the uniform steps that each user story, task, or requirement goes through from start to acceptance.

Example States

  1. Backlog
  2. Defined
  3. In-Progress
  4. Completed
  5. Accepted

Exit Agreement

The Exit Agreement is the agreement amongst the team members of the criteria that must be met in order for a work item to move to the next step in the workflow.

Swimlanes

Swimlanes are a more conceptual element that revolves around how work is segmented, whether it be by functional group or priority.

Example Swimlanes

  1. Expedited vs Not Expedited
  2. Owner

Vanilla Kanban Model

The Vanilla Kanban Model leverages the most basic states that tend to follow work products in IT project. The Vanilla model consists of the following states:

  1. Backlog
  2. Defined
  3. In-Progress
  4. Completed
  5. Accepted

Example

Backlog Defined In-Progress Completed Accepted
US2345
US3456




US0954



US6543
US0943


US94310





US23476

Exit Criteria

Backlog Defined In-Progress Completed Accepted
1. Product Owner or Dev team needs to identify the user story (who wants what and why?)
2. Product Owner needs to specify Acceptance Criteria.
1. Developer needs to have met with the Product Owner to have Story Time and fully understand the User Story and Acceptance Criteria, and update together if necessary.
2. Development team needs to have defined all tasks necessary for completion of Acceptance Criteria.
3. User Story needs to have a Development team owner.
4. Story Points must be assigned.
1.All tasks are completed - work is done and verified by a tester.
2. User story must be deployed to staging and verified again by a tester.
3. Code is checked into Git.
1. User Story has been demonstrated to Product Owner and Acceptance Criteria verified.
2. Deployment Script or Steps have been created.
1. User Story is deployed to Production.
2. Product Owner has Accepted the User Story.

Swimlanes

The Vanilla model does contain any specific swimlanes

About

This site is dedicated to documenting and sharing the TSD Agile SDLC Process. It is a living breating set of documentation that will grow as our divisions maturity with Agile grows

Our Bunker

1800f street N.W.
Washington, D.C.
United States.