At XPDays 2015, we presented the session “Sharpen your story splitting skills”.
In the end people left with the shared knowledge from the other attendents and as a cherry on the cake a useful deck of cards with splitting patterns. 
This session can be called a success, but still I had the feeling this subject needed more attention to effectively help people.

When the big stories do not fit in a sprint, they need to be split.
Even though we know a story needs to be split, this task is often avoided.  Side effects emerge:  

• “Let the PO do this!”,
• “Let’s increase Sprint size!”,
• “Let’s just ignore it, and start working”,
• …

Hence the motivation for our session at XPDays 2015.

Background

When we would look at it more closely, splitting as such isn’t the primary problem. Sometimes not even secondary!  It usually is part of a complex network of interactive relationships.

That’s why it’s so hard to pinpoint the reasons why so many struggle with splitting and get stuck in anything that relates to splitting.  
You can guess that being stuck isn’t really an enabler for improvement-oriented thinking. 
The consequence is the skill of splitting doesn’t get much of attention, and we remain on status-quo.

Why is that?

Usually below the surface, dysfunctions of many kinds offer the soil of this paralyzing problem.
This post is part of a series that explains these dysfunctions in order to understand the basic practices to counter them. 

When to split?

Sometimes we see that early splitting happens, even if it is in a granular way. 

Why is that?

It seems we tend to overrate the value of imaginary constructing, building, analysing, but also splitting.
We overrate it thát much that we make detailed plans how things should be built.
Moreover, we believe having a dedicated role for doing this kind of knowledge work is an advantage.

What we forget, however, is that building from an imaginary approach shines for describing the end state, but lacks understanding all the exact intermediate states in between.
In other words, it’s very hard to know an intermediate state since it’s depending on so many factors at that point in time.  

Now, we can all agree on the fact that building (in reality) depends very strongly on what has been built before, right?  Yup, “building” is an activity that highly depends on what’s already in place.
If a house has no foundations, starting to build walls according to schedule isn’t the best idea ever.
If a house for some reason has bad foundations, construction workers will act differently than when foundations are top quality. Follow-the-plan could even be recipe for disaster.

Sure, we pretend to know intermediate states, we build Gantt charts, decompose into work packages, etc…  But I guess we all know that a plan stands for how it should be happening. Reality contradicts our wishful thinking. Cold showers ensue.
Construction workers have to anticipate their way out.  

Actually, anticipating is their most underrated skill!

As overrated imaginary construction is, as underrated anticipation is.

Imagine yourself as a developer.
The work is already split up.  Will you re-do that split work?  Guess not. Feels like a waste of time, doesn’t it?
So as the splitting has been determined upfront, the work to be done usually follows that deconstructed split-up.  Even if the “proposed split” -how this is often called btw- is not correct, or costing time, still re-doing the splitting feels like a waste of time.

And it is, kind of. 

“So when to split then?!”  

As late as possible is the answer.  
We call this principle J.I.T. (just in time)

Why J.I.T. splitting?

As explained above, 

• to maximise flexibility and anticipation in how to build. (regarding the how, another post follows, I promise)
• to minimise the time wasted on imaginary constructing deviating from real constructing.
  Imaginary constructing has a high degree of uncertainty. And so does all the work it is based on.

Consequences upfront splitting? Check this:

• Splitting itself costs time too! But that isn’t the nasty part…
• Since we have split, there is some explaining to do: reasons, arguing, explaining. This knowledge sharing could be in between team members, but also (worse) from somebody outside the Team who isn’t actually involved in building. (on the who another post follows, I promise) 
  No matter how you put it, knowledge transfer is needed, and therefore, costs time.
• And as if it couldn’t get any worse, another secondary consequence is waiting for us.
  Ever seen backlog items nicely split up, but not estimated?  It almost hurts the eye, isn’t it? 
  On top, if there is no pressure-for-numbers already, usually there is at least one person in the organisation who’s waiting for these estimates.  Which cost time.  
• All the above produce numbers. As explained in “The evils of chasing Scrum Velocity” we have a strong tendency to correlate cause and effect. 
  This drives us to see the cause and effects in metrics with numbers. 
  In “Detailed metrics are not always the answer” you can read about the consequences of detailing by numbers. 
  So what happens?  People start building reports and metrics on top of them. 
  Those metrics usually do not add value to the end customer, and cost time.

As you can see, upfront splitting causes all kind of other upfront activities. Yet they are highly uncertain as they are the consequence of imaginary constructing. 
So chances are high a bad wake-up call is welcoming us (again).

J.I.T. splitting: How?

Before we start keeping our upfront-split items away from daylight from the number chasers, let’s consider not splitting upfront at all…  But how do you do that?

Good splitting practices consist usually out of several ingredients. Here are some tips to consider: 

• In Scrum, split only what’s needed to tackle in a Sprint and add a bit more to assure the Team can pick from the backlog in times of prosperity.
• Make the split sessions a habit by making a ceremony of it.  E.g. every two weeks a session.
  The Backlog Refinement session is the best candidate. 
• Assure all people from the team are present.  
  The higher the diversity, the lower chances are mistakes will go undetected. 
  All people are informed about the backlog items, and the splitting can be agreed by all, or better options can be discussed. 
  No need to re-explain and delegate info from one to another.

Very nice, but what about…?

• “Our analysis needs time!!”  
• “And what will all my analysts do?!“
• “Our architects need to figure things out!”
• “We need at least a sprint to analyse!“
• “But I want my metrics!”
• …
•  

As you can see, just one of the many reasons to argue for upfront splitting.
They all have one thing in common though… 
None of them can argue the painful waste of time, none of them is able to solve the risks that come with it …  

Starting from the bottom of the list, you can check the articles mentioned in this post.
Additionally on the sprint-to-analyse dysfunction you’ll find this article most interesting: Why Sprint n-1 Analysis is a Bad idea. 

In the following post I’ll try to touch on the first 3 arguments from the above list.
They are commonly heard reasons, as they are about “who” is doing the splitting work.

Stay tuned for the next episode of this splitting the backlog series!