There is a story card on our wall estimated to 8 points. It’s so easy to tear it down and put two new 3- and 5-point cards instead of that big one. Cool, we can even move one of them to the next sprint. No, no, no…
But wait there is another story in our backlog. This one is big… No problem – lets split it into smaller functionalities. Yes… and yes!
So what’s the point? Is there a problem in splitting stories anyway? The short answer is “yes and no”. It’s because the problem lies not in splitting stories, but in the moment when we do it. There are usually to points in time when we think about dividing stories into smaller parts: release/sprint planning and the end of current sprint.
This is the moment when we think about stories before we start implementing them. We choose what is possible to do within the planned period of time. We gather detailed information about stories that should be implemented first. This is the moment when we try to plan the work that fits into our capacity usually driven by some observations of our recent velocity and other factors.
At this point we may find some stories to be too big to fit into the sprint, but we realize that we can split them into smaller independent parts that are still able to bring value to our clients. We choose more valuable stories and leave the other for a better time or even get rid of them. This is where I say YES to splitting stories.
End of sprint
Next time we tend to think about splitting stories at the end of our sprints. This is caused by one reason – we just can’t finish the story by the end of the sprint. We thought we will, but (again) it wast one story too much. Actually we have it almost done. And this “almost done” tempts us to split the story, leave the finished part in the current sprint while moving just the unfinished chunk into the next timebox. Hurray! Our velocity, charts and metrics have been saved once again!
This is the moment what I say NO to splitting stories. Story should be either fully completed or moved to next sprint. And yes, velocity should drop this time. This is the only way to spot the problem in the long term. Ok, it’s not a problem when it happens once. But if we will break down stories at the end of the sprint regularly to keep our velocity untouched then we may miss the root problem (there will be no sign of it, except for a not so happy face of our PM/SM who needed to tell our client about yet another unfinished story).
The root problem of unfinished stories may be:
- (most likely) wishful thinking – we keep thinking that we can do more this time and load our sprints with too much stories
- too short iterations – the amount of features for the increment is good (less of them would not give any usable product) but we try to implement them in to short iterations, so maybe one week is to little and we should switch to two weeks
- inaccurate estimations – if we have lots of unfinished stories every sprint this means that those stories tend to take more time than we thought and if it keeps happening then we should rather reestimate some of them and try better understand what they are about
So think about when you usually split your stories? Maybe it’s time to look deeper into your process.