Extreme Story Slicing (Part 2)

In the previous post we looked at the benefits of slicing vertically, as well as the advantages of working with smaller stories. In this post, we will look at how we can ensure that we have good stories, where we stumble in the process and how we can go about slicing stories up.

INVESTing

Bill Wake came up with the INVEST acronym, which you can use to help you see if you have a well-defined story. The acronym stands for the following:

• Independant - A story should be self-contained and no dependencies on other stories.
• Negotiable - The stories are not set in stone and can be changed until they are part of the sprint.
• Valuable - It must have value to the end user. If it has no value, then it shouldn't be done.
• Estimable - You should always be able to estimate your story. If you cannot do this, it is an indication that it may either be too large, or it needs to be spiked.
• Small - The stories should ideally be between 1-5 days.
• Testable - A story should always have acceptance criteria and be able to be tested.

Where We Stumble

Even though we often have the best intentions at heart, we struggle to get it right. So why is that? For me personally, in the first few years of my career, I often believed in trying to futureproof solutions and tried to ensure that they would cater for the numerous possibilities that could be thrown at it. In hindsight, this was extremely foolish as it almost never worked out and is one of the reasons that stories tend to get larger and larger.

One of the most important lessons I learnt is YAGNI

Another stumbling block for me personally was that I always wanted to deliver the perfect solution first time. Again, in hindsight, this was completely wrong and goes against everything that has been said about delivering small stories with incremental value. I quite like the way that Ian put by saying something along the following lines:

If you are delivering a polished apple, you are doing it wrong.

How Do We Slice?

So how do we go about slicing stories? One of the metaphors that was given to us was to think of the finest thread that we could create to cut through all the layers of the system, that can provide a single piece of value. The way I like to think of it in my head is how do we achieve the Minimal Viable Product (MVP) for an extremely simple version of the happy path. After that, you can add on the other requirements one by one, until the end goal is reached. Again, this is delivering value in an incremental fashion.

So just how big should these slices be? A rough guideline that was provided to us was that stories should take a few days & tasks should take a few hours. Again, these are guidelines and can be adjusted to suit your team.

It's Not Easy

For me personally, thinking like this is not easy. I'm used to larger stories and trying to break them down and slicing them down in this manner takes conscious effort. Over time I have no doubt that it will become easier to do and as Frederick Douglass put it

If there is no struggle, there is no progress.

Until next time...keep learning!