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.