Story is about change

It seems self-evident that story is only about change - when it gets done, it becomes part of the baseline. However, in practice, I often observe that people don't make the distinction between change and baseline, which causes pains.

Mixing change and baseline

Let's look at the below example.

create a person with same name
  • response with success or failure
  • failure includes reason
  • attributes include name and title
  • name begins with letter and has less than 20 characters
  • if the name already exists, create a variant (lv yi -> lv yi.1)
  • title is either developer or coach

This is a story from an application of people management. It is about creating a person with same name. While it looks good, there is confusion about what the change is. Is it the whole functionality of creating a person, or is it only the part dealing with same name?

As story is about change, let us only describe the change. The updated story could be as below.

deal with same name
  • if the name already exists, create a variant (lv yi -> lv yi.1)

Isn't it easier to understand this story than the first one? It only focuses on the change, while leaving out the existing part.

But, isn't the first one more self-contained, thus more convenient in the way developers can learn about related parts - both existing and new - all at once? Indeed, changes are scattered, and they are not friendly for learning the big picture. This calls for baseline.

Missing baseline

Baseline accumulates all changes till now. Once we implement a change, the change becomes part of the baseline.

It is surprisingly common that we don't maintain a baseline, only changes along the way. Missing baseline is the deep issue, and it causes various pains.

How do we learn about the application? We should learn from the baseline, but we haven't maintained it except the application itself or user manual.

How do we make a full regression? We should test against the baseline, but all the details especially expected results are described in the changes. In order to do it properly, we have to re-establish the baseline from the changes, but in practice we seldom do it, because doing it all at once is painstaking. Instead, we do a little bit, for example, creating a set of smoke tests, which is essentially a minimum baseline. Of course, the better way is to establish the baseline from the beginning, and maintain it all along. This can be something as below.

create a person
  • response with success or failure
  • failure includes reason
  • attributes include name and title
  • name begins with letter and has less than 20 characters
  • if the name already exists, create a variant (lv yi -> lv yi.1)
  • title is either developer or coach

Notice that this is not a story, but a baseline functionality of creating a person. Several stories may have changed this functionality, but this is what it is now.

Although this can be a baseline document we maintain all along (the stories can be thrown away after it is developed), the better form is automated tests, which becomes living documentation. You may learn more from "Specification By Example".

I believe that understanding this distinction can help make our product development more sustainable.

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