Story splitting is a widely spread activity that enables teams to deliver results quickly and efficiently. Still, it doesn’t come without its challenges. The concept of story splitting can be really powerful if it’s done with the right motivation.
Imagine you are a big fan of Michelin star restaurants and you decide to celebrate your 10-year wedding anniversary in the brand-new place, which has just opened nearby. You would probably want to dive head-first into the organization, carefully arranging all the details for the event, like the music, drinks and meals.
However, before you set anything in stone, if you’re anything like me, you’ll definitely want to speak directly to the chef first. You may even arrange a short rehearsal to taste the meals and the wines in advance, so you can make sure everything goes as smoothly as possible.
They love this approach because serving one meal to make sure that’s exactly what their customers expect is much better than serving 100 meals which turn out to be a rather unpleasant surprise.
Splitting the work into smaller pieces will make it easier to manage but none of it will make sense if you don’t account for the fact that each piece should be meaningful to your customer.
The most important part of the story splitting process is to preserve the concept of customer value.
Your Customer’s Perspective Matters the Most
If you are a Scrum practitioner, it’s very likely that you split your stories to make them fit into a sprint. And this activity is something that you need to pay careful attention to.
Always think about story splitting from a client’s perspective. Put yourself in their shoes. When you split your stories, ask yourself “What is the most feasible option that will still solve my customer’s problem?”. That should always be your starting point. The stories on your kanban board should represent work items that are first and foremost meaningful to the customer.
Now you might be thinking “Sonya, you can’t always deliver items that are meaningful to the customer in every sprint”. Let’s break this statement down.
Let’s assume you are a software development agency and you have to develop a payment portal. Can you provide the user interface so your customer can see how they will interact with your solution? Or is it possible to provide credit card payment integration first before jumping into Wire Transfer, PayPal or Bitcoin support?
What about all the components behind the scene? Does your customer care or not whether you have set up routers and load balancers?
I started my career as a software developer, and if you’d asked me 15 years ago I would probably have said, “No, why would the customer care about the backend implementation?”
A load balancer acts as the “traffic cop” sitting in front of your servers and routing client requests across all the servers capable of fulfilling those requests in a manner that maximizes speed and capacity utilization and ensures that no one server is overworked, which could degrade performance.
Let’s rephrase the question a bit: Does your customer care whether your solution is fast, cost-effective and reliable? Well, definitely “Yes”. Therefore, setting up routers and load balancers is meaningful for your customers.
When you’re splitting your stories, think about what is the easiest and fastest way to provide a deliverable to your clients. The goal is to deliver results and collect their feedback sooner so you can adjust your course accordingly.
The nature of knowledge work is unpredictable. In knowledge work, we make assumptions about the future. In the most effective manner, we validate these assumptions by delivering results early and often. We learn what brings value and avoid the risk of spending time and effort on the wrong things.
You Should Split Your Stories in a Continuous Manner
Splitting your stories is a continuous process. It’s not something that happens before the work moves through the process.
As your team works through a story in the development workflow, you gain more and more information. If it happens that the story turned out to be way more complicated than you initially assumed, it’s imperative to ask the question: Is it possible to break down this story so we can actually deliver something to our customers to solve their problems in a timely manner?
And the Aging Chart is the tool at your disposal to help you make that decision. This chart offers a detailed overview of where your tasks are in your process and how much time every task spent in progress so far.
The horizontal axis outlines all workflow states while the vertical axis shows how many days a certain task has spent in the workflow. The higher the dot, the longer the task is taking to complete, and the higher the chances of a delay.
The Aging Chart builds over your past data to provide you with a solid guideline on how your current tasks are progressing. The percentile lines that run alongside the vertical axis indicate the percentage of tasks that were previously completed. For example, if a task is climbing past the 50th percentile line, it means it is already taking more time than half of your previously completed tasks.
The Aging Chart will tell you whether your current work in progress has already taken more time than the work you’ve already delivered.
It will enable you to spark the conversations around “Did we right-size the story or should we go back to it again in terms of scope and figure out the best approach to deliver customer value quickly?”.
And if you’re interested in going deeper into right-sizing your stories to establishing stable predictable delivery workflows, I’d be thrilled to welcome you to our Sustainable Predictability program.
When you define your stories, try to make them as small as possible while still preserving the concept of customer value. As long as your stories represent the most feasible options your customers will benefit from, you’ve done a great job to meet your customer’s expectations while enabling sustainable business agility.
