Experiments on Daily Scrum

The purpose of Daily Scrum is for team to inspect and adapt towards Sprint goal. The mechanics seem so simple, while in practice its purpose is often not well achieved. Here's some experiments that may help you find better mechanics to achieve purpose.


  • Separate "inspection" and "adaptation" questions

If you look at 3 defined questions, "what did you do since last Daily Scrum?" and "what got in your way?" are questions to help team inspect; while "what will you do until next Daily Scrum?" is question to help team adapt. In typical Daily Scrum, every team member reports to each other with 3 questions in one round. I have found that it is more effective, as well as more natural, to do in two rounds. In the first round, everybody reports with 2 "inspection" questions, then, update sprint burndown and other information that helps understand where we are towards Sprint goal. In the second round, we focus on the "adaptation" question, which is essentially a daily planning or re-planning.


  • Story focus rather than people focus

In traditional format of daily Scrum, people take turns to report. When the team is big (e.g. 7-8 people), and/or there are many ongoing stories (e.g. more than 3), it is hard to learn the big picture by listening to everybody reporting in round robin. The adaptation is rather accidental and individual oriented. It improves when you create story focus by reporting on stories in priority order. People working on the story report status and impediments, team as a whole adapts.


  • Better focus by limiting WIP

When WIP (the number of ongoing stories) is high, it makes it hard to focus while inspecting and adapting. Inspection and adaptation become easier when you only look at small number of stories. You may physically create fewer lanes in your task board, and pull story only when there is empty lane.


  • Sprint Burndown variants for better transparency

Sprint Burndown provides transparency for inspection. Traditionally, burndown is on tasks, everyday we re-estimate to get the remaining hours on tasks. Does it provide good transparency to help us understand how far we are towards our sprint goal? Does it incur much cost? You want to achieve best transparency with minimal cost, thus, teams experiment various burndown techniques.


  • Some teams simplify this by not re-estimating tasks, but burndown only when task is done. This reduces the cost of re-estimating, and they find that the transparency doesn't suffer, instead, it is actually closer to reality because often the last 20% of task takes 80% of efforts.
  • Some teams burndown stories. With the support of good engineering practices (continuous integration, ATDD, etc.), they are able to see the progress on story level within the sprint. This provides better transparency in the spirit of "working software is the primary measure of progress".
  • Some teams think that the story granularity is still too coarse for progress tracking within the sprint. They burndown acceptance tests. While doing ATDD, they track passing acceptance tests as progress indicator, which is still based on working software.


  • Coaching with GROW

ScrumMaster coaches team on inspection and adaption. GROW (Goal-Reality-Options-Will) is a simple coaching model for awareness and responsibility. "Goal" and "Reality" questions are great in helping team raise awareness during inspecting; while "Options" and "Will" questions are great in helping team take responsibility during adapting.


Keep the purpose of daily scrum in mind, experiment different mechanics to better achieve the purpose.

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