Kanban Process Framework

Kanban is a lean scheduling system used for software development. Its aim is to visualize and improve any software development process. The end result is a development pipeline that is predictably and efficiently delivering high value work.

Core Principles:

Visualize the workflow: A visual representation of your work allows you to understand the big picture and see how the flow of work progresses. By making all the work visible, including blockers and queues, you can identify issues early on and improve collaboration.
Limit work in progress (WIP): Work in progress limits (WIP limits) determine the minimum and maximum amount of work for each column on the board or for each workflow. By putting a limit on WIP, you can increase speed and flexibility, and reduce the need for prioritizing tasks.
Manage and enhance the flow: The flow of work (the movement of work) throughout the Kanban board should be monitored and improved upon. Ideally, you want a fast, smooth flow, which shows that the team is creating value quickly. The team should analyze problems in the flow then implement changes.
Make process policies explicit: In order for collaborative change to occur in the Kanban system, the processes need to be explicit. Everyone needs to understand how things work or what “done” really means. You can modify the board to make these processes more clear; for example, you could redesign it to specify how the work should flow.
Continuously improve: The Kanban method encourages small, continuous changes that stick. Once the Kanban system is in place, the team will be able to identify and understand issues and suggest improvements. Teams measure their effectiveness by tracking flow, measuring cycle time, and increasing quality of work.

Kanban Process Flow:

The following graphical representation helps illustrate a Kanban Process flow:

Tool used: Atlassian JIRA and Confluence

We normally use Atlassian JIRA to track the development progress and Atlassian Confluence for documenting project artifacts. While explaining the Kanban process, you will find below various screenshot from JIRA explaining the process and tools together.

Kanban using JIRA:

A typical Kanban board has three columns: To Do, In Progress and Done. We can however customize the columns or workflow status as per our need for visualization.

The Kanban board for working has two main items:

Backlog
Backlog is the place where you can add your to-dos. In most of the cases the work items are not organized and they appear in the order they have been added. You can think of it like your idea vault or else said – “all the work that could be done”
Workflow:
The Workflow has three stages. It doesn’t matter how it’s structured, how complex it is or how many different columns it has. The stages are Ready for Dev, In Progress and Done.

To Do: You place the prioritized list of work that need to be developed here. The JIRA issues are ordered top to bottom based on their priority. The items from this queue goes upstream to the next queue or let’s say “In Progress” for example when they are estimated and ready for development.
In Progress – Every item that has been pulled from the “Backlog” and hasn’t been completed yet is “In Progress” state. Even if you have started to work on a given item and then you stopped, it is “In Progress”. And it remains so until it is completed or removed from the flow. If you see the Kanban board below, the WIP limit for In Progress column is set to 5.
Done – This is the state where all items that have been completed are pulled from the “In Progress” column. In Kanban, there isn’t such a thing like “almost done”. If it is not completely done then it is still “In Progress”. JIRA issues can be tagged with versions and released after once they are in Done column.

Release Version: The JIRA tickets which are moved to the done column once they have been approved from UAT/deployed are assigned a fix version based on a specific standard that is maintained by the team to track respective releases. A version is a set of features and fixes released together as a single update to the application. Assigning the tickets with a versions helps to mark and track the releases that have been delivered. In JIRA Software, we can also view tickets based on which version they belong to.

Swimlane: A swimlane is a horizontal categorization of issues in work mode. For eg, you can add a swimlane for hot fix or issues that needs to be expedited. In the figure below, we can see two swimlanes, Expedite and Everything Else.

Defining Labels:

Feedback
During the development phase, a close collaboration is required among Team members and the Product Owner. To add ease to these feedback sessions, every progress about a task is roofed under a single User Story. “Feedback_required” can also be used as a label to easily filter issues in the Kanban board to list only those tickets which need feedback. The clients can provide feedback in the comment section of the ticket.
Tracking Change requirements:
Working on Agile, the changes are a welcome addition as we know the the changing business environment might result in changes in the initially defined requirements. In such cases, tracking changes become essential. The tracking is done using labels in JIRA and assigning them to the respective issues. In the screenshot below, a label “change_requirement” has been introduced to group the feature that has been changed from the initial plan:

Change Request in JIRA

When to add change request in To-Do list?

If the change request has lesser business value than the ongoing task then it can be added to the To-Do list and reprioritized accordingly.

When to swap current task with change request?

If the stakeholders decide that the current task does not add much value to business, then we can hold the current task and swap with the change request.

How to track change request using JIRA?

We can make use of labels for tracking change request.
We can create a new issue type for change request (if needed)

We use “change_requirement” as labels in JIRA issues to identify the tasks that has been requested change. Please see the figure below for example.

changerequirement label.png

We keep a record of change log in confluence. Below is an example of a log.

S.No	JIRA #	Description	Estimated time	Requested by?	Approved by?	Status	Date requested	Release affected
1	NSN-20	Add a 'Report Error' button in the resource directory detail popup which will allow the user to report any errors to the admin	16 hrs	Client (Sage)	Client (Sage)	Added to backlog	06/02/2017	Release 1 - 07/24/2017

Control Chart

A Control Chart can show the cycle time or lead time for your product, version or sprint. The horizontal x-axis in a Control Chart indicates time, and the vertical y-axis indicates the number of days issues have spent in those statuses.

Agile Meetings(borrowed from best practices in SCRUM):

Daily Standup

The Daily Standup is a 15-minute time-boxed event for the Development Team to inspect progress toward the Iteration/Milestone Goal. During the meeting, the Development Team explains:

What did I do yesterday?
What will I do today?
Do I see any impediment that prevents me or the Development Team?

Retrospective Meeting

In the Retrospective Meeting, the team reflects on how they are doing and to find ways to improve. The Retrospective is an opportunity for the Development Team to inspect itself and create a plan for improvements to be enacted during the next iteration. We store the meeting minutes in Confluence.

Search in JIRA

We can easily search for issues in JIRA. Navigate to Issues (in header) > Search for issues, then enter your search criteria. The search results can also be saved, exported and used for reporting purposes. We can also extract reports using Search for Confluence.

Browser not supported