Look at your sprint board for a moment.
If three or four items are almost done, one story is waiting on testing, another is on the back end, and the most important story moving into the next
sprint again, the problem probably isn't that the team didn't work hard enough.
The deeper problem is this, your team is finishing tasks but not finishing value.
In this video, I'll show you why that happens, how teams accidentally hide unfinished work inside their stories, and a simple test you can use to tell
whether something is really a story or just a task.
I'm Mike Cohn.
I've spent decades helping agile teams write better user stories.
And this is one of the most common patterns I see.
A team works hard, all sprint.
Everyone's busy.
Real progress is made.
But at the sprint review, the more important story still isn't done.
The backend works, but the interface isn' connected.
the happy path works.
but edge cases aren't tested.
The feature is close, but no one is comfortable calling it complete.
So the story moves into the next sprint.
When that happens occasionally, it may just be bad luck.
when it happens regularly, look first at how the Story was split.
Teams often think they have a capacity problem or commitment problem when the real issue is a splitting problem.
Big stories are hard to finish, but the bigger issue is that teams often break stories down in ways that still prevent anything usable from being completed.
Work moves, tasks get checked off, the board looks active, But the value is still trapped inside something larger that isn't done yet.
And in Agile, unfinished value is the same as no value.
That's where story splitting helps, when it's done correctly.
Story splitting means more than just making stories smaller.
It means creating smaller stories that each deliver something meaningful on their own.
The goal of story splitting is to release value sooner.
Let me show you what usually goes wrong.
A team has a story like this.
As a home buyer, I can search for a Home based on size, rooms, status, type, age, and amenities.
That's a big story.
So the team splits it by technical layer.
One backlog item for the user interface, one for back end, One for database and one testing.
That may look like progress, but nothing usable exists yet.
No one wants a search screen that doesn't search, and no one can use a database query without an interface.
The team has divided the work, But the value is still locked inside the larger story.
the team's finishing pieces of work but not finishing anything a user can actually use.
A better approach is to split vertically.
Do a little of the user interface, a lot of back end, little database work, and enough testing to make something work end to end.
For the home search example, the first story might be, as a prospective home buyer, I can search for a home based on size and number of rooms.
That's smaller.
It's incomplete compared with the full capability, but for what it includes, it works.
Now the team has finished something real.
A later story can add status and type of home.
Another story could add age and amenity searching.
Each story unlocks more value.
That's the shift from completing tasks to delivering value!
This is where teams confuse story splitting with task splitting.
Tasks describe activities.
Stories describe outcomes.
A task says, build database tables.
A story says a customer can complete a payment.
Here's the test I like.
After this is done, can someone do something they couldn't do before?
If yes, you probably have a story.
If no, You probably a task, even if you called it a Story.
If this sounds familiar on your team, this is exactly the kind of thing we help companies improve in our private agile training.
We work with teams to write better stories, split work more effectively, and make finishing meaningful work inside a sprint more realistic.
I'll include a link below if your company wants help with that.
One reason this matters is that big work hides uncertainty.
You've probably seen this, a story is 90% done.
A week later, it's still 90%. The developer was being sincere when they said they were 90%, but additional complexity showed up and finishing the story
got bigger.
Small outcome-based stories avoid this.
They move cleanly from not started to done and they expose risk earlier.
As a rough guide, be cautious of any story that can take half of a sprint.
That's usually a sign that value is bundled together instead of being delivered incrementally.
Good teams work with much smaller stories, not because small is automatically better, but because finishing is better.
So what makes a good split?
Someone can do something new when it's done.
The team can finish it comfortably within a sprint.
It cuts vertically through their product instead of separating the interface backend database and testing into separate backlog items.
Its clear enough that the team understands what must be true for this item to be considered complete.
And it creates value, even if it is only one small part of a larger capability.
Sometimes the team will say, this story cannot be split.
My first response, try harder.
Not harshly, but realistically.
Most teams give up too soon.
They try one or two obvious splits, usually technical layers.
And when those don't work, they give-up on splitting the story.
That's why I use Spider.
It gives teams multiple ways to find splits.
Spike, paths, interfaces, data, and rules.
If one type of split doesn't work, try another.
So when a story feels too large, don't ask, how can we divide the work?
Ask instead, what's the smallest piece of value we could deliver?
Can we support one path first?
can We defer an edge case?
We limit the scope to one persona, one data source, or one rule?
Are we creating smaller stories?
You're just disguising tasks as stories.
And most importantly, what must be true for this to be done?
If your stories keep carrying over, your team may not be failing to finish.
They may be finishing the wrong things.
The fix is to make the unit of work small enough that finishing something meaningful is realistic.
If you want a practical way to find those smaller value-based splits, watch my spider video next.
It gives you five ways to split a story when the obvious split doesn't work.
Thanks for watching.