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.
Every time I think about story splitting, I am immediately reminded of Goldielocks and the Three Bears. A young girl’s quest to find the perfect tasting porridge and unequaled chair. It’s easy to draw parallels between relative story sizing and this well-known fable.
Regardless of degree of Agile maturity, the size of the stories our squads are working on and their ability to split is an ongoing issue. Different teams have different challenges. Some stories are too big. Others are too small. This week I look at how to identify issues with story sizing, and showcase possible mechanisms to help identify when to break them down to a size that is 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.
tions across these teams. We cannot compare their velocity. Despite management objections, we push to prevent comparison across teams. The relative comparison of story points should be across a single squad. It is the responsibility of each individual Scrum team to regulate story size, and split as they see fit.
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.
There has been significant debate on the maximum size. Concerns are that splitting the story may mean the value is lost. Regardless, the majority agree that a story must be small enough to achieve in a single sprint. This item was not, and therefore needed to be broken down.
Our initial approach to break the story by each environment still resulted in rollover. As the work progressed, more undocumented components required upgrade. More legacy technologies required remediation. Hindsight teaches us that had we been able to isolate each component for upgrade, along with the at risk processes, each story could have been smaller and manageable. Their value would also have been easier to communicate to clients, and the resulting progress would have been more transparent.
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.
This degree of collaboration has proven to be a double edged sword. Having greater engagement means we are getting more clarifications of user needs and product strategy. We obtain behavioural scenarios as acceptance criteria. However we still receive large sets of bullet points as additional acceptance criteria. While developers strive to meet the full criteria, in the ever changing criteria items are often missed, leading to defects being raised later.
This has got me thinking of the old tactile approach of using index cards for our stories. Despite the numerous benefits, a side-effect of using automated tools such as Jira and Trello is that we cannot regulate the amount of detail using the size of the index card. Be mindful of the amount of criteria specified for any given story. Consider using our current rule of thumb, where if the criteria won’t fit on a single side of an index card, your story needs to be split.
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.
The above symptoms are classic manifestations of too big stories. The next question on our lips is what techniques can we use to break stories down. My research has identified several approaches to help without efforts. Initial thoughts are that the generic words and acceptance criteria approaches are particularly useful. Only time, and a future post, will tell how effective these techniques prove to be.
Thanks for reading! Claps and comments are always appreciated.
