7 stages of delivery - an example Kanban
What does my Kanban board look like?
After my recent series of posts on building a Kanban, I was asked to share an example of a real Kanban. To that end, I want to share with you a great example of a Kanban board that one of my previous clients used in a Business Intelligence service delivery context. This is obviously an example, and your own Kanban board should be build and improved based on your own processes and observations.
Like any Kanban, team members are responsible for selecting the next task to work on, delivering that task and ensuring that verification, testing and documentation are completed prior to completion (and migration to production). We have encouraged an environment where team members proactively interact with their colleagues (and any external parties as required) to progress the assigned task to completion.
Note; the WIP limits below are for a team of 5
Stage 1. Backlog (WIP: ∞)
The Backlog is the set of tasks that need to be delivered. These are triaged and put into the Kanban board. Based on the logical sequencing of tasks and agreed prioritisation, the team members select the next task to work on and promote this to the "In Progress" state.
WIP Limit: There can be infinite tasks in this state (however, it may take a while to complete them all)
Average Time in State: 3-20 days
Stage 2. Impact Analysis (WIP: 1)
The Impact Analysis state is where the team member researches and investigates the scope and impact of the tasks. This may include a high-level impact statement where a task could affect existing products or services.
WIP Limit: There can only be one task analysed at a time.
Average Time in State: The analysis state will take between 5 minutes to 1 hour.
Stage 3. Build (WIP: 3)
The Build state is where tasks are actively being worked on. Once the task has been completed and tested, the team member promotes it to the "UAT" or "Release" state.
Build tasks include the following types of activity being performed:
- Design
- Build
- Test
- Technical Documentation
- Deployment to the Testing environment
WIP Limit: There can be three tasks being built simultaneously at a time.
Average Time in State: The build state may take anywhere between an hour to a week.
Stage 4. User Acceptance Testing (WIP: 6)
This is an optional step and can be skipped for tasks that were not initiated by an external Customer. During this state, the User Acceptance Testing is performed by the customer, and the Team is responsible for following up on testing progress and resolving any issues or defects raised.
WIP Limit: Due to the expected waiting/blocking nature of UAT, there can be six tasks being tested simultaneously at a time.
Average Time in State: UAT may take up to two weeks.
Stage 5. Release (WIP: 3)
Once the task has been approved by the customer (or team leader) it is submitted for release to production. The release state may include some, or all, of the following components.
- Physical Implementation Design (PID)
- Transition Plan
- Rollout Procedures
- Rollback Procedures
- Support & Troubleshooting Guide
Depending on the type and scale of the tasks, the authority to release either sits with the team leader or with the change advisory board (CAB). If CAB approval is required, an RFC is raised at to drive the release to production. Where the release has impacts on external business areas, any relevant documentation is created and handed over to the relevant teams.
Once released, a selected set of tests will be run in production to verify the results are consistent with what was observed in previous environments.
WIP Limit: The team can release three tasks simultaneously (to reduce the risk of an artificial bottlenecks caused by the CAB process).
Average Time in State: The release state may take anywhere between an hour to a week.
Stage 6. Documentation (WIP: 1)
During this state, the team member produces, updates and communicates any relevant documentation (including diagrams). At the same time, the service desk ticket is closed. We originally had the Documentation state prior to deployment but experience and feedback, for this team, showed that there was less waste if it was after.
WIP Limit: We have artificially reduced the WIP to encourage bottlenecks, and thus encourage documentation to be completed in a timely manner.
Average Time in State: The documentation state will take less than one day.
Stage 7. Done (WIP: ∞)
Tasks are considered “Done” when:
- A deliverable has been produced against the requirement and meets development standards
- Functional tests written and passed
- System tested and passed
- Quality assurance reviewed
- The task deploys without errors
WIP Limit: There can be infinite tasks in this state
Average Time in State: N/A