I first came across the idea of story slicing at Agile North when Seb Rose ran a workshop about it. Our primary goal was to slice a story for a twitter clone from memory this was the ability to post a tweet of 120 chars. I recall during the exercise we never quite sliced thinly enough, with Seb always challenging us to slice thinner. Eventually the initial slice was just a web page with a text box to enter some text no restrictions. I thought at the time this slice was way too thin, with little or no value – I really struggled to understand slicing so aggressively.
I’ve tried over the last 4 or 5 years to understand slicing and apply it more in my every day to work. Some environments allow this, and some don’t.
The example that I’ve come up across recently is getting the product information for a product on an ecommerce site from a different place. This is my attempt at slicing it thinly:
- Pick a single product
- Feature switch getting the title for the view from existing location to be hard coded in the view
- Push back the hard coding back through the architecture – i.e. this might be calling a api to retrieve the data
- Manually enter the title in to the product store & retrieve from there
Each slice should be deployed and monitored. There are other tasks contained in each of these thin slices – like monitoring and setting up deployment pipelines potentially. However, these steps shouldn’t take that long.
By slicing this thinly you can learn about your architecture and get the walking skelton in place relatively quickly. Therefore, understanding if you have any issues with the path you are taking.
You could then expand this out to another product or build out some other capability.
The take home is try to half what you do now, then once you get good at that, half it again. You should aim to get something delivered every day which extends your understanding of the problem domain.