Definition of Done or Working agreement?

Definition of Done is the agreement between Product Owner and team. As ultimate goal, team is delivering potentially shippable product increment every sprint, thus, your Definition of Done shall be equal to what's required to make your product increment potentially shippable. However, your current Done may be only part of what's needed to get potentially shippable, constrained by your current technical capability. When we defined our Definition of Done several years ago, I found that we also added some criteria that are not really part of what's required for being potentially shippable. For example, we may make our product potentially shippable without automating the tests, though we added automated tests into our definition of Done. Why did we add them? Because we'd like to make sure that our development is sustainable. If we rely on manual tests, we shall soon find that regression efforts go up exponentially. We can not really afford, thus, we may not do regression in full all the time. Then, every now and then, we break existing functionality without knowing it. What's in Done and potentially shippable is actually no broken old functionality, while test automation is a practical mean towards that. I realized that there are two kinds of criteria in Definition of Done. One is customer/product and result oriented, which are all required to become potentially shippable; the other is process oriented, which defines the way of working. Over time, i also noticed that when team got mature, they tended to have less process oriented criteria in their definition of Done.


During a recent co-training with my colleague Emerson, I learnt from him that he always included those process-oriented criteria into working agreement. That is interesting, and it makes me wonder why we took different approaches and what differences they actually have. Here's my thoughts. Although it seems trivial since team will do according to both Done and working agreement anyway, there are profound differences. Scrum team is self-managing under certain boundaries. The most important ones are timebox in sprint, and Definition of Done. Organization and Product Owner executes the control through setting the boundary, while team self-manages within the boundary. Working agreement is completely up to team, thus, it's not part of the boundary set by the organization and Product Owner. In my environment, while we adopted Scrum, the concerns about self-managing still prevailed and the feeling of uncertainty from management was still strong. Thus, we kept more control by setting strict boundary through adding more process oriented criteria into Done. On the contrary, Emerson's environment seemed putting more trust on team, thus, they left those to the working agreement, which is created and owned completely by team. Either consciously or unconsciously, we chose the different approaches based on different assumptions and level of trust, and control.


Have you noticed the difference and what's the assumption behind your approach?

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