12. September 2018
4 min

Story slicing – benefits of the #NoEstimates approach

The Story

Last week I had the opportunity to demonstrate the value of the #NoEstimates approach in real life. A Product Owner asked me for advice how to handle a change to the affected User Stories that came up late.

The need was to replace a database update mechanism to an existing application. The logical sequence of work to do was like:

  • Replace the trigger for data updates
  • Implement a web service call to retrieve the updates (web service already existed)
  • Implement a mechanism to ensure updates don’t get lost (e.g. in case the service is unavailable)
  • Update necessary data in the application retrieved by the web service
  • Remove the current update mechanism

Story slicing – how it’s often done

So there were five stories in place – one for each step. By slicing it this way, no story itself creates “End to End” (E2E) value but inherently depends on all other stories to be finished, a direct consequence of so called “horizontal” slicing. Horizontal slicing is an “all or nothing” concept that reminds me to the old waterfall world:  Value is provided in a binary way at the end of a very large project. Either you get all the value or nothing. Sometimes work is even divided according to specialists (e.g. Frontend, backend, database experts) which further complicates integration of the whole.

The problem starts!

Once the team started working on the first User Story, changes came up. The mapping of the data was updated several times, which in turn forced the updates of several other User Stories. Further, it turned out that the most important data field to wasn’t available in the web service. So we needed to provide the missing field information to store the data which required changes to more than one story. And the team was already working on one of those… You see where this is going… A big mess…

You can genuinely tell that the story wasn’t ready. But which is? By starting the work, new information arises and this needs to be dealt with. This is the reason why we work in an Agile manner: expect and embrace change.

So why not start small “End to End”?

E2E slicing (also called vertcal slicing) is to allow for iterative incremental delivery of value. Take a step back and ask yourself: What is the easiest way to provide an E2E value in a very small time frame (e.g. half a day or even less)? In this example, we could provide a very small subset of data all the way through from trigger to the DB update and a test case that fits the implementation. Every part described above can have a very lightweight implementation that will be enhanced in the next stories. This way it will be easy to describe late changes by adding a new User Story and schedule as needed in the Product Backlog. More importantly, new User Stories don’t invalidate previous work, they improve it!


Motivation – how embarrassing is it to tell the developers that we need to change a bunch of User Stories we already talked about (or worse estimated / already in the current sprint and of course someone comes up with re-estimation)? How do you feel if you just implemented one thing while being told “Ahem – we need to change this Story”? You think you’re done but once this happens you feel like “how many of these kind  of changes are sitting out there waiting to come up”. When we slice User Stories vertically or E2E, we provide a meaningful task for someone to deliver results instead of a small part that only makes real sense when several other User Stories are implemented and tested.

Story handling – It is much simpler to describe only the changes that come up late in one new User Story instead of trying to figure out the changes to several (already implemented) User Stories which may be in different status along the development process.

Risk reduction – Implementing a lightweight E2E slice of functionality reduces risk and reveals problems early because it forces us to think through the whole process, not just one step.

Tests – Simply evolve E2E tests in every story and you can be sure there is always something that you can show. Preferably by starting with the test (TDD, ATDD, …).

Integration effort vs. specialization advantages – Slicing work horizontally (or not according to value) assumes that integration efforts are small compared to specialization advantages of each horizontal slice. Think back to the old days of waterfall (or horizontal slicing of work): how often did you find yourself in a situation where you thought all the steps were “done” and you experienced endless Bug-Bugfix-Retest cycles?

The assumption that specialization is always beneficial (and the best approach) is seldom challenged and similar patterns apply all the way up to the organizational level (project, program, organization…). Specialists are “excellent for achieving highly efficient execution of known, repeatable processes at scale” (Team of Teams, 2015, S.52). Is this how your software development looks like? If that is the case, then be ready to be replaced by machines or outpaced by the competition. In Team of Teams, the author details plenty of success stories and catastrophic failures, and in those pay attention of how integration was either properly addressed or neglected.


#NoEstimates isn’t just about “skip the boring estimation”, rather it aims to create value as early as possible. Don’t slice work (steps, horizontal), slice value (E2E, vertical). A small implementation slice that leads to an improvement compared to before is the real incremental iterative value delivery promised by the Agile movement. After all, you don’t eat Bruschetta basil first. Do you?


Team of Teams – New rules of engagement for a complex world. General Stanley McChrystal, Portfolio Penguin, 2015

Comment article


  1. Harald

    Hi Mike, danke Dir!!! Mich würde das genauer interessieren was ihr macht – möchtest Du eure “success story” auch zur Verfügung stellen?

  2. Mike Götz

    Danke für den Artikel. Nach nunmehr einem Jahr Produktentwicklung im Rahmen eines Kundenprojekts ist es genau der Ansatz der unser Team erfolgreich macht. Jeder Product Owner sollte sich das ganze mal durchlesen.