When is ‘Done’, truly 100% ‘Done’?
5 Dec 2017
When working through any Product Backlog, it’s essential that the whole Scrum Team have a clearly defined and mutually agreed understanding of when each backlog item can be deemed as complete. Without this collective and transparent agreement, teams may struggle to get product backlog items 100% truly ‘Done’ within a Sprint. This is explained further by the Scrum Guide; “When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means. Although this varies significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the definition of “Done” for the Scrum Team and is used to assess when work is complete on the product Increment.” The Scrum Guide (p.16) The below example of ‘Done’ is fairly typical for a team early on in its adoption of Scrum within a corporate environment. Activity (Example) Criteria (Example) Detailed Analysis Acceptance Tests approved by Product Owner. Wiki updated. Detailed Design Consistent with approved design patterns and UI standards. Design approved by Architect. Overall Design Doc updated. Build & Unit Test Consistent with coding standards. Peer Reviewed. 90% automated unit test coverage. All unit tests […]
As well as being a popular term for the big visible wall charts and boards that Agile teams use, Kanban (literally translated from Japanese as ‘visual card’ or ‘sign’) is also the name of an evolving, and increasingly popular Lean Agile method in its own right.
However, the method is neither a development process nor a management framework. Rather it is a method for gradual evolutionary change driven by ‘pull systems’. Instead of planning what work will be done in advance, a limit is placed on work-in-progress based on capacity. New work is pulled from the queue only when something is finished – Just-in-Time – in order to create a continuous flow of delivery.
The Principles of Kanban
The Principles of Kanban are:
- Start with what you do now
- Pursue incremental, evolutionary change (unless there is real appetite for revolution!)
- Initially, respect and do not seek to change current roles, responsibilities & job titles
- Encourage acts of leadership at all levels
Suitability of Kanban
The agil8 approach is to recommend the overall Kanban method for organisational change where there is no appetite for the revolutionary introduction of new roles and practices that come with other Agile approaches.
This method is particularly suitable for those teams who find it difficult to plan their work in advance such as those doing support, maintenance and operations. Pull systems work very natutrally for such teams. However, the faster flow of value to the customer which Kanban promotes is clearly something that could benefit any team – even those already using another Agile method. Thus it can be used to great effect with Scrum, an approach often referred to as Scrumban.
Achieving Faster Flow
To get faster flow, Kanban focuses on driving down lead time by applying queueing theory. One way to reduce the lead time of delivery to the customer is to speed the rate at which each piece of work is completed. The other way, which is usually easier in software development, is to limit the amount of work in progress. With a team of fixed capacity, the more items there are in progress, the longer the customer will have to wait for each one. Switching tasks and context between multiple items also takes time.
Kanban limits the number of items to capacity rather than having work pushed onto the team. It also encourages the team to split work into smaller pieces that can be delivered incrementally. It encourages teams to reduce re-work by building quality in, and reduce waiting because of hand-offs, gold plating or impediments. Having to wait is particularly dangerous as the temptation is always to start another piece of work which will of course increase the lead time of everything else in progress. Thus identifying and removing bottlenecks and working as a cross functional team to help each other finish work is particularly important in Kanban.
The Core Practices of Kanban
The core practices are:
- Visualize the workflow on a Kanban Board to understand it
- Limit work-in-progress to expose impediments and waste
- Manage the work to flow effectively by removing impediments and wasteful practices
- Make process policies explicit (e.g., queues, work item and service types, Definitions of Done, etc.)
- Improve collaboratively, guiding the evolution using models and a ‘scientific’ method
- Implement feedback loops between team members in the workflow, between teams, and via the manager coaching team members
Kanban with Scrum and Other Agile Methods
Many Kanban concepts are present in other Agile methods. Sprints effectively limit work in progress, and the breakdown of work into small potentially releasable increments with cross functional teams help minimise waiting and smooth flow. However, this goes beyond the regular Sprint cycles of Scrum and all other Agile methods. It allows planning, delivery, review and retrospective to happen at any time to suit the team independently of each other. Thus Kanban has found popularity amongst experienced Agile teams who find their existing Agile process too restrictive.