How Scrum team benefits from Kanban practices

While discussing some struggles of Scrum team with my friend He Mian during his Kanban course recently, i realize that Scrum team can benefit from many Kanban practices.

There are 6 core practices defined in Kanban method. They are:

  1. Visualize
  2. Limit Work-in-progress
  3. Manage Flow
  4. Make Policies Explicit
  5. Implement Feedback Loops
  6. Improve Collaboratively, Evolve Experimentally

Let's look through them to see how Scrum team or any team doing iterations can benefit from those Kanban practices.

  • Visualize

Scrum team usually adopts some form of task boards to help coordinate their work in sprint. The key is to effectively inspect where we are so as to adapt accordingly. Visualization in Kanban goes deeper than usual task board. When the cycle time of your stories is still long (e.g. a week or more), the additional details expose problems earlier and help us adapt faster. Kanban uses more elements when visualizing, such as area, color, shape, number, etc. For example, the impediment could be visualized as attached note with different color on the story. This brings everybody's attention immediately.

  • Limit Work-in-progress

Scrum limits WIP indirectly by iteration. It's recommended to work on one story at a time, however, it may not be viable with small size story (e.g. 2-3 days, 2-3 people) and big size team (e.g. 7-9 people). It is good practice to limit WIP further inside sprint, and visualize that by limiting the number of lanes for example. One argument against doing that may be the risks involved in not starting the work, considering that the goal is to complete them all by the end of the sprint. We shall take risk factors into account when prioritizing stories. By limiting WIP, we actually improve the chance of completing them all by the end of sprint.

  • Manage flow

When managing the progress, reminder of sprint goal is a good step forward, while focusing on flow provides more clear guidance. Anything that prevents flow becomes impediment.

Bottleneck is one common reason that prevents flow. In Kanban, a few ways are suggested to address those both in the short term and in the long term. For example, when testing becomes bottleneck, you may first consider removing any non-bottleneck work from those people who are testing; then, you may consider improving quality of the work flowing there by doing more developer tests; then, you may consider having developers help testing. Scrum team benefits from ideas of flow management.

By measuring cycle time - the time you start working on a story till the time you get the story done, you get insights from control chart and distribution chart on how to improve the flow in the long term.

The focus on managing flow is also reflected in the way that daily standup is done in Kanban. We walk through the board from right to left, story by story. This helps making more effective inspection and adaptation.

  • Make Policies Explicit

The Definition of Done (DoD) is one of the most important policies in Scrum. The Definition of Ready (DoR) gets popular in Scrum community, which is another policy. BTW, in practice those may lead to the wrong focus on handover from one group to another, but those could be and are achieved collaboratively in many contexts.

Many Scrum teams create and evolve their working agreement, which forms a dynamic set of processes and policies. Kanban points out more opportunities to make policies explicit, and they become areas for improvement. This fits well with the inspection and adaptation on process. Only when you understand how you do things now, can you improve further. The improvement involves the update of policies, which becomes the baseline of next improvement. Scrum teams benefit from treating working agreement as the carrier of continuous improvement. And the working agreement is visualized in the board.

  • Implement Feedback Loops

There are 3 practices defined as feedback loops - daily standup, improvement kata and operational review. We have talked about daily standup in managing flow, and let's look at the other two.

Improvement kata is the daily improvement activity. I have been promoting the paring of manager and ScrumMaster on process improvement. Usually, they work together on removing impediments. The impediments may come from daily scrum or retrospective. Kanban measures flow, and provides the feedback with data. The data is systematic, and supplements well for the impediments. Operational review acts as feedback loop in large scale. The key again lies at the analysis of data.

In Scrum, two levels of feedback are built-in, daily and sprint. Daily feedback is provided through status sharing in daily scrum and sprint burndown. Sprint feedback is provided through conversation in sprint review and release burndown, as well as sprint retrospective. Comparing to metrics defined in Kanban, such as cycle time control chart and distribution chart, CFD, etc., those feedback in Scrum is more subjective. Scrum team benefits from integrating more data in the feedback loop. In particular, we shall consider gathering objective data in sprint retrospective to achieve more balanced view and better insights.

  • Improve Collaboratively, Evolve Experimentally

The improvement practice in Kanban emphasizes using models and the scientific method. The requires more rigidity in our improvement activities. While it is one direction to improve retrospective through more effective facilitation so as to increase team engagement and promote ownership, it is another direction to improve retrospective through more rigid analysis and followup. I have seen teams applying PDCA in their retrospective and reaping solid benefits.


Even though flow and iteration are different concepts and practices, when we dive deep, we find that Scrum teams benefit from doing some Kanban practices.

  • use visualization to help inspection
  • limit WIP for flow
  • use flow to guide adaptation
  • improve on DoD, DoR and working agreement
  • create feedback from data
  • retrospective with data

Read more

Scrum master ทำแค่เนี๊ยะ

Scrum master ทำแค่เนี๊ยะ

เวลามีคนถามว่า Scrum master ทำอะไร แล้วผมตอบว่าทำให้ Scrum เวิร์คสำหรับทั้งองค์กร ซึ่ง โฟกัสหลัก ๆ 4 อย่างก็จะอยู่ที่ Product owner, ทีม, engineering practices และ องค์กร บางครั้งที่ผมจะได้ยินเสียงตอบกลับมาเบา ๆ ว่า “แค่เนี๊ยะ?” ในฐานะ

By Chokchai
how to สร้าง Knowledge Management

how to สร้าง Knowledge Management

ตอนเรียน Large Scale Scrum กับ Jurgen de Smet สิ่งหนึ่งที่ผมได้เรียนรู้ คือ ปัจจัยสำคัญหนึ่งที่ทำให้องค์กรหนึ่ง ๆ จะเร็วขึ้นได้ คือ จะต้องเรียนรู้ไปพร้อม ๆ กันได้ ซึ่งถ้าอยากทำแบบนั้นได้ก็จะต้อง share ownership

By Chokchai
โลกการเขียนโค้ด ตอน ซามูไรกับสปาตั้น

โลกการเขียนโค้ด ตอน ซามูไรกับสปาตั้น

ซามูไรที่ได้รับความไว้วางใจให้แก้ core logic จะมีสัญชาตญาณซามูไร คือแก้ตรงนี้ จับยามสามตาแล้วรู้เลยว่าจะไประเบิดตรงโน้น แล้ววิ่งไปสกัดบั๊กไว้ก่อนความเสียหายจะเกิด (ถ้าเป็นในหนัง ตอนนี้เป็นบทที่บั๊กร้องว่า “มืงรู้ได้ไง?!” :D) หลังจากที

By Chokchai
ประสบการณ์ TDD

ประสบการณ์ TDD

มันมีบางชั่วขณะ ที่ผมอินกับ Test-Driven Development (TDD) มาก จนอยากจะแนะนำทักษะนี้ให้คนเขียนโค้ดทั่วโลกที่สนใจเลย ผมคิดว่า ทักษะนี้มีผลเยอะมาก ๆ กับความรู้ความชำนาญในการเขียนโค้ดของผมทุกวันนี้ แต่ที่ผมไม่เคยอธิบายเป็นคำพูดออกมาได้คือ ทำไมนะ? เมื่อเช้าตอนกำลังอ่านเกี

By Chokchai