Same Size Feet

Identifying the Need for Story Splitting

We all remember our favourite childhood fairytales. Despite being significantly short, they all follow a similar format. Each story arriving at the perfect ending following the protagonist overcoming strife.

Image for post
Image for post
Much like the chair in Goldielocks and the Three Bears, User Story size must also be just right

Shapes and Sizes

The primary manifestation of poor splitting is a large variation in the size of stories on the backlog. Most squads in our area have significant stories in their backlog, intermingled with small single point defects. One team is better than most at creating smaller stories. Even then, their range can massively fluctuate.

Image for post
Image for post
Having large variance in story sizing makes it diffcult to track velocity and compare stories for future estimation

It’s Only Rock and Roll

A secondary symptom we have encountered is regular rollover. Large infrastructure upgrades on a legacy system have been a key example in our space. Having a single story was not viable for several reasons. Legacy systems are often poorly documented, making identification of dependencies difficult. Larger systems also require significant work to upgrade as well.

Image for post
Image for post
Stories regularly rolling over across sprints suggests it is not well understood, and potentially that it is a larger story that must be split

Blue Condition

Another warning sign that I’ve recently encountered is the length of the acceptance criteria associated with a given story. As part of our increased collaboration with BAs and our engaged PO, a larger amount of detail will accompany each story.

Image for post
Image for post
Developers are regularly bamboozled and trapped by the sheer amount of acceptance criteria that underpins our stories

Price Tag

Where we struggle to split using the above indicators, our ability to break down and estimate the story is our final mechanism to verify a story is not too big. As simple as it sounds, if we cannot comprehend how to break it down, or the story decomposes into a large number of sub tasks, it’s time to split the story down. Our prior rollover example certainly was partially caused by being unable to estimate the original story.

Image for post
Image for post
If we cannot understand or estimate a story, it’s most likely too big for the team and must be split

Lead software engineer with a strong interest in Agile, UX and Usability. Lover of cooking, tea, photography and gin!

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store