November 28, 2018

Extreme Story Slicing (Part 1)

A introspective look at how we can slice and break down user stories and the benefits that come with it.

Extreme Story Slicing (Part 1)

I recently attended a talk by Ian Hughes during our latest Back2Base Event at Readify. It was titled "Extreme Story Slicing" and he went into detail on how to split up your user stories into smaller chunks of work with increasing functionality. It sounds easier than it is, as I tend to be in the mindset of delivering fully functional pieces and to get out of that frame of mind can be quite challenging.

Vertical Slicing

So what exactly is meant by vertical slicing? Well, there are two main ways of slicing work, namely horizontally and vertically. If you were to slice horizontally, you would take a layer of your solution, say the UI, and complete that as a whole. However, if you slice vertically, you would do a component from end to end, so in this example it would be from the UI all the way to the database.

The issue with slicing horizontally is that you tend to have people being blocked and "hanging around" waiting for work to finish before they can continue their tasks. Ironically, this is something that has been recently happening our project as we were slicing horizontally. The other problem is that with this approach, none of the stories generate value by themselves and require the bulk of the stories to be completed before any benefit is realised. Essentially, we are breaking down work in a waterfall manner where the value is only realized right at the end. As a result, this makes proper testing very difficult to do.

Smaller Stories

Another thing that we were consistently seeing is that a lot of the stories were being carried across into the following sprint. I believe that this was a symptom of our stories being too large. So, what is the benefit of breaking stories down? I mean, at the end of the day they both land up with the same result. For me, the answer lies in the following benefits, which will be realised along the way:

  • Provides More Focus Smaller stories provide much more focus. I myself have been guilty of expanding stories to include "one more thing", as it is easy to get lost in the details of such a large story.
  • Easier to Test Testing small pieces of code is much simpler than testing the behemoth of a story that you have been working on for the whole sprint.
  • Adaptable When you have small chunks of work it makes it easier to pivot and adapt to changes as they come up.
  • Small Pull Requests A side effect of small stories is that it can make it easier to have smaller pull requests to review. Again, I have been guilty of having large PR's in the past, and by taking this approach it helps you fall into the pit of success.
  • Delivering More Value As I mentioned before having larger stories will decrease your ability to consistently deliver something of value to the customer. After all, that is what being agile is all about.
  • Increased Team Momentum We recently came out of a sprint where we completed almost no stories. This was quite demoralising for me as it seemed like no work was actually done and even left our product owner somewhat disappointed. By having smaller stories being completed more often, the entire team can see that things are moving forward and help drive the momentum to push things forward.

So that wraps up this first part in this series of posts. Next time I will be going over how to ensure that we have good stories and how to slice them up.

Until next time...keep learning!