Why Split User Stories, Anyway?

Why Split User Stories, Anyway?

Product Owners are accountable for outlining the expectations of their desired Product. User stories communicate the need between the users, stakeholders and engineering team. The Scrum Team starts the conversation with the user story. They use the user story to continue the conversation and to get more just in time information as needed. The Product Backlog will contain varying levels of detail. There will be small items and larger ones prioritized based on value. Let’s provide some detail on reason to split user stories.

Simplify Complex User Stories

“Life is really simple, but we insist on making it complicated.” – Confucius

Good user stories are small enough to complete in one single sprint. It is the reason provided for splitting most user stories. Also, complex user stories are hard to understand and deal with. They can contain connected or interrelated parts. Understand and can contain interrelated part along with unknowns. The origin of complexity can be hard to find. Both technical and business complexities exist.

There is an idiom that many people use when something is complex, break it down. Take a moment to find the smaller pieces. Think about solving the problem differently. Hence, find value from the perspective of the user. If you can’t find it, think of another users perspective. Also, look for the one or two things that make it complex and separate them. Pull the team together to harness everyone’s ideas.

Compliance And Business Rules

Every business has a designated set of Business Rules that all user story paths must follow. These rules are often for industry compliance, government regulations, or internal policy compliance. These rules come from all parts of the organization to the Product Owner. For example, a free shipping perk occurs the purchased of $50 or more. The development will implement this user stories. They may need to find ways to carve out some of these rules or group them.

Deliver Superior Options

The end users are always looking for more value. Products are there to meet that need. The ability to “supersize,” add innovative ideas or modern options is imperative. In addition, the Product Owner will guide in the right direction based on what they have learned. With every new option, comes another split. For example, having five payment processing options—and adding cryptocurrency as a sixth.

To Clear Up Uncertainty

At times, It is difficult to pin down the users need. Other times, technology offers a new unproven path. The cases need research. When this occurs, the team will often carve out a “spike” from the user story. Remember a spike is time-bound research activity to clarify something. This helps with uncertainty. As the team learns, the user is updated with the latest information. This often leads to at least a few splits, both in the spike and in a few other user stories. Spikes should only be added when there is genuine uncertainty. This will save time and money when the work gets done right the first time.

Deliver A Minimally Marketable Features

We live in a day and age where products are rarely 100 percent complete. This is not said to be discouraging. Our needs are evolving more rapidly than ever before in history. Our products must evolve to meet the ever-changing industry needs and client expectations. There must be a measurable point at which a product is released. This point is often the minimally marketable features. The release of MMF will lead to the more advanced features. Product Owner will rank each one.

Even if not for an MMF, the prioritization of the Product Backlog encourages feedback sooner. For example, we expected to release the MMF to millennials in silicon valley. It is decided to implement 3 of 5 payment options.

Conclusion

The most important thing to keep in mind is the benefit to the user. It can be a major fight with an engineering team that is used to tasks. It is easy for them to split stories based on engineering steps, i.e., Frontend, backend, and database. Product Owner can not prioritize engineering steps. Think about the end user and split to improve things for them.

Happy Trails!

This article is Part 3 of 6. Next up, horizontal splitting vs. vertical splitting.

Take a look at the other parts of this series.
Part 1 – User Story – Start With Training Wheels
Part 2 – 7 Common Mistakes Splitting Stories


Leave a Reply

Your email address will not be published. Required fields are marked *