Columns #
The following columns are defined in the Development Board. Each column has individual policies to move and pull issues from/to there.
| Stage | Description |
|---|---|
| Pipeline | Issues are collected but not yet ready for development and moved to the board. Tickets on top must be prioritized so that they can be moved to SELECTED. |
| Selected (for Development)WIP 10 | Issues in here are categorized in one of the four classes of service. Issues are pulled from here to IN PROGRESS by the developer team. |
| In ProgressWIP 5 | Issue is corrently in progress. Not more than 2 tickets per developer (WIP Limit). |
| In Review / Waiting | Issues that are implemented from a developers perspective are moved to IN REVIEW. It does not matter if a merge request is still pending or has already been approved. |
| Waiting for Approval | An issue is moved to WAITING FOR APPROVAL when the merge request to master has passed and the changes are deployed to Staging environment. |
| Done | Tested and approved issues are moved to DONE by the one who is responsible for the issue. In most cases the reporting person. Done issues will be deployed to Production during the next release. |
WIP Limits #
Setting WIP (work in progress) limits is a key property in Kanban for a number of reasons:
– Teach teams to focus on getting things done.
– Prevent tasks from accumulating at any step in the process.
– Allow teams to know their true capacity.
– Expose blockers, bottlenecks, and inefficiencies.
– Help prevent teams from being overburdened or lax.
Setting WIP limits enforces teams to only work on what they can. This helps in managing the flow of work through a Kanban system.
WIP is limited to the maximum amount of weekly throughput in column SELECTED FOR DEVELOPMENT to have the flexibility of re-prioritizing on a weekly basis.
WIP is limited to the number of developers in column IN PROGRESS to reduce parallel development work.
Classes of Service #
Kanban classes of service provide structure and governance for how teams should handle incoming work.
- Expedite +5%
- Fixed Delivery Date 20%
- Standard 50%
- Intangible 30%
Cost of delay is the main determinant when classifying and prioritizing work items.
Open image-20201002-090237.png
Expedite #
This class of service is for critical and top priority items that require immediate handling. An expedite item preempts other work and requires teams to ensure no interruptions are experienced in the workflow.
Critical production issues, server breakdowns, network defects, and patches are examples of an expedite item.
Fixed Date #
This class of service is for work items that have a significant cost of delay, if not delivered on a fixed delivery date. Items that fall under this class are prioritized where necessary to be finished on or before the target deadline. If the team falls behind schedule, fixed date items would usually be promoted to expedite in order to speed up the process.
Samples of fixed delivery date items are those related to contractual or regulatory obligations and seasonal business.
Standard #
Items that fall under this class of service aim to solve business and customer requirements without a fixed timeline or sense of urgency.
Intangible #
Items that fall under this class of service are those that are useful but do not have a significant cost of delay.
Quality improvements and optimization work would normally fall under this classification.
Kanban Meetings #
Daily Standup #
At the daily standup the team discusses and organizes the tasks to be performed that day, analyzes blockages and looks for ways to resolve them.
In Kanban, the daily standup should not focus on the individual employees, but rather on the work that needs to be done.
Weekly Focus / Planning #
Weekly planning meeting to focus on development topics of the week.
Priorities / Queue Replenishment Meeting #
Currently not implemented
In the regular queue replenishment meeting meeting the order of the tickets to be processed is determined. At this meeting, all those who give tasks to the team should be involved.
Release Planning #
The release planning is attended by all those who are necessary for the release. Developers, testers, configuration managers and business analysts.
Monthly Backlog Cleanup #
Meeting between Product Owner and 1 Developer to prioritize the backlog. Tickets older than 6 months will be deleted.
Retrospective #
The retrospective aims to review the work and cooperation of a certain period and to draw conclusions about what could be improved.
Retrospectives can take place regularly, but should also be held dynamically in case of problems.
Estimations #
A detailed estimation at Kanban does not have to take place. Instead the duration of tasks are expressed in T-Shirt sizes (small, medium, large).
- S: 1-2 days
- M: 3-5 days
- L: 6-10 days
Anything larger than L must be split up into smaller tasks