1. Based on the "Kanban and Scrum - making the most of both" book by Henrik Kniberg, Mattias Skarin
2. Further reading
2.1. STAYING AGILE - 5 Best Practices in Software Project Management
3. Kanban
3.1. Kanban in a nutshell
3.1.1. Visualize the workflow
3.1.1.1. Split the work into pieces, write each item on a card and put on the wall.
3.1.1.2. Use named columns to illustrate where each item is in the workflow.
3.1.2. Limit Work In Progress (WIP) – assign explicit limits to how many items may be in progress at each workflow state.
3.1.2.1. The WIP limit is per workflow state (lane), not per person
3.1.2.2. Experiment with the exact number for the WIP, there should be a good balance between the lanes, no deadlocks
3.1.2.3. Too low kanban limit => idle people => bad productivity
3.1.2.4. Too high kanban limit => idle tasks => bad lead time
3.1.3. Measure the lead time (average time to complete one item, sometimes called “cycle time”), optimize the process to make lead time as small and predictable as possible.
3.2. Kanban limits WIP per workflow state
3.3. New items can be added in the "Todo" workflow state if its WIP allows for it
3.4. Kanban doesn't prescribe any estimation or velocity
3.5. No charts are prescribed, but Cumulative Flow diagrams are often used
3.6. In Practice
3.6.1. Break down todo items into up to 8 hours tasks
3.6.2. Daily standup
3.6.2.1. similar to a daily scrum
3.6.2.2. proposing solutions and prioritizing decisions
3.6.3. Iteration planning
3.6.3.1. Update charts and board.
3.6.3.2. Look back at the last week. What happened? Why was it so? What could be done to improve it?
3.6.3.3. Readjustment of WIP limit (if needed).
3.6.3.4. Task breakdown and estimation of new project [if needed].
4. Scrum
4.1. Scrum in a nutshell
4.1.1. Split your organization into small, cross-functional, self- organizing teams.
4.1.2. Split your work into a list of small, concrete deliverables. Sort the list by priority and estimate the relative effort of each item.
4.1.3. Split time into short fixed-length iterations (usually 1 – 4 weeks), with potentially shippable code demonstrated after each iteration.
4.1.4. Optimize the release plan and update priorities in collaboration with the customer, based on insights gained by inspecting the release after each iteration.
4.1.5. Optimize the process by having a retrospective after each iteration.
4.2. 3 roles: Product Owner (sets product vision & priorities), Team (implements the product) and Scrum Master (removes impediments and provides process leadership)
4.3. Scrum limits WIP per iteration
4.4. Scrum resists change within an iteration
4.4.1. No items can be added to the scrum board during an iteration, the earliest is the next iteration
4.5. Scrum prescribes estimation and velocity
4.5.1. Velocity is a measure of capacity – how much stuff we can deliver per sprint.