Inspired by #NoEstimation movement I’d like to share my ideas of story splitting as there are plenty of ways how to do so.

A common understanding

Teams struggle sometimes in getting a common understanding of what to do to create software and to contribute to a specific outcome. Usually the Product Owner is assigned to write down a consolidated view into user stories.

Source: Jeff Patton about User Story Mapping

Off topic: Use product discovery for making a difference

Enough said, that this is a late stage to discuss what to build, so I exclude product discovery for this post, but if you want to understand more about it, have a look at the slides.

The challenge with user stories

In general there are plenty of ways how to express yourself and get into a discussion about what to build. Most popular are user stories which are sliced and expressed for development teams to have a common understanding what to build. User Stories are widely used in similar formats like this:

As a < type of user >, I want < some goal > so that < some reason >.

Source: Michael Cohn about User Stories.

The question of those user stories is about the right sizes and whom to address. It is very important for the product owner to get a clear and sharp distinction and expression for the various partners to articulate. As well as for the team to get appropriate user stories to finish work within a sprint.

Using Gherkin for acceptance criterias and user story splitting

A very popular way in splitting user stories is from AgileForAll. I always had a look at this to gain a broader expression to write down the appropriate level of information. Since last year I’m practicing Gherkin when writing user stories and acceptance criteria and it helped a lot to slice thinner and add value to manual testing and test automation. Gherkin look like this:

 1: Feature: Some terse yet descriptive text of what is desired

 2: Textual description of the business value of this feature

 3: Business rules that govern the scope of the feature

 4: Any additional information that will make the feature easier to understand

 5: 

 6: Scenario: Some determinable business situation

 7: Given some precondition

 8: And some other precondition

 9: When some action by the actor

10: And some other action

11: And yet another action

12: Then some testable outcome is achieved

13: And something else we can check happens too

14: 

15: Scenario: A different situation

16: ...

The way of working with features, epics and user stories is very helpful and basic for product owners. As I’m very workflow driven when it comes to user journeys and mapping, I found it very helpful to use Gherkin Given-When-Then steps to slice user stories and write them down.

Split multiple given-when-then steps and write a new user story.

This simple method really helped me in splitting and writing better user stories. Why are they better user stories? Because those user stories are more granular and can be better prioritized.

Credits to Timon Reinhard who introduced Gherkin in our CoP.

Better ideas or feedback? Let us know.

Thanks,

Patrick