In a sequence of blog posts based on our “Sharpen your story splitting skills” at XPDays 2015 to frame our useful deck of cards with splitting patterns, we bring you the last blogpost about how to split backlog items. 

Background

Many times during our session we got questions like:
“What’s the best pattern?“
“Can you give us advice on how to split?“
“When to apply which pattern?“
“How should we split?“

This article will handle aspects of a good split.  

The problem

Unfortunately, the reason why splitting isn’t that popular has roots in many causes.

Overhead

“That’s overhead!” “Let me just do my job!”
As stated in the previous post, highly complex problems should be faced with high diversity.
Splitting is a necessary skill that the Team should acquire. 

Comfort zone

Splitting is out of our comfortzone: “Let the architect do it!” 
Yet, this leads to postponing the problem of thinking on how to tackle the story: 

• too far upfront, as someone else takes care of it. Someone who will take his time.
• too late; That is to say during the Sprint.

Mislead

Tell you what: Actually these were the very same questions in the Background section above we wanted to provide an answer to in our first draft sessions…
Luckily our colleagues at Co-Learning helped out in shaping our session design. 

People do not need to be told what to do…
They needed to be inspired, and given sufficient background info to get out of discomfort and feel confident enough to start splitting.

Either way you put it, these kinds of questions are all root to the same problem: “tell me what to do… please?”
The answer, though, is that you should point your question to yourself, and turn the question around: “what would be the best split for us as a Team, given the situation at hand?” 

INVEST: curse or blessing?

In Scrum trainings people are been told what the characteristics of a good quality story are: INVEST. 
I ndependant 
N egotiatable
V aluable
E stimatable
S mall
T estable

Frequently we see that INVEST is perceived as acceptance criteria for proper story splits.
Meeting all aspects in the famous acronym is hard. Rarely all letters of the acronym are met.  Rarely.
When we look at the impact this assumption has on the activity of splitting itself, we can tell that INVEST ends up as a reason for reluctance rather than a helping hand to start splitting.
On top: Since INVEST is in many Scrum guides and references, it becomes the “official” reason why splitting-is-not-possible becomes a paralyzing justification.

So how do we have to understand INVEST then?    

As a guideline, and not a contract that must be met! 
As a reminder to understand the things that matter for backlog items, and what’s important to keep in mind when splitting.
So, when we’re not having the “I” (independent), this should be telling us: “watch it, you’ll be having dependent backlog items. Take care of it!” 
(Going deeper into the topic, check the following article about the activity of managing dependencies.)
Or, when we’re having the “V” (valuable) not met, shouldn’t we put some effort in how-to-explain-this in the Review session, so our customer understands what it means for him?

So indeed INVEST can be a blessing. As an awareness tool.

A solution

But what should a good story look like? 
When do we know when a story is well-split?
The answer to that question is remarkably simple.  Taking the above into account:  You’ll know.
Why?
Because you’ll have payed enough attention to all letters of the acronym; whether some letters are covered or not: you took care of it in terms of risk. 

Advice

There are however some things to keep into account. 
Story descriptions should best be kept as a problem rather than solution.
When we put solution-like things in a story they are been perceived as predefined, and cannot change as such. 
Why?  How the “solution” is being built is the responsibility of the ones making it, and should also be owned by them.  
That involves any design, choice in architecture, choice in technology, choice on look-and-feel,  choice of testing… 
Why? They are the ones that look the beast in the eyes when implementing.
They know the code inside out. They are best person for the job.
“Not for us! They are newbies!”  Train them instead of “letting the take care of it”. 

Negotiate

When splitting, we want something big to chop off in pieces. 

How? 

By means of collaboration.  “Huh? Say what?” 
Collaboration, between the ones wanting their problem to be solved (PO, Stakeholders) and the ones providing the solution. (Team) 

The most simple way of exchanging information is through a conversation. It’s very natural. 
And in that conversation ask yourselves the following question:

“How can we redefine the scope of that backlog item so that the item becomes sufficiently small and simple enough so I can  

• understand? “
• implement, and I concretely know what to do? “

If the above criteria are not met:  re-iterate, and refine that scope!  Until the criteria are met.  
“Noooo!!”  “I want the FULL scope implemented!!”  
Ofcourse, the scope demand stays. No worries.  

The difference a refinement makes: we’ll understand each of the pieces the full scope consists of.  Also in terms of value. 

Sometimes the value is not high, sometimes it is.  But we’ve done the exercise of thinking what it means to our customer. 
Do not mistake: This strategy is very powerful! 

Why? 

Making it sufficiently small removes the uncertainties out of the backlog items at hand.

Also, reducing the scope of something gives two very interesting and valuable aspects: 

• The new scope (refined)
• The old scope (full)

Simple huh? 
It is the difference in them that can point you to your split strategy! 

Example

Imagine a screen with all kinds of widgets on it. Checkboxes, edit fields, drop downs, radio buttons,… 

Suppose you negotiate and redefine the scope to the functionality of what a button is supposed to do.  And the full functionality of that button can be implemented is sufficiently small that 

• the developer understands is
• the developer concretely knows what to do

By knowing the difference in between the refined scope and the full scope, we know that next item to build the initial scope might be the next widget to tackle:  the edit field, (and so on.)  
Well there you go:  This split strategy we call the “Tracer bullet”

Or suppose you negotiate and refine scope to the creation of the UI only, mocked off with stubs. 
Well there you go: Next item to build the full scope might be the underlaying ORM that matches all UI widgets. (and so on.) 

Or suppose you negotiate and refine scope to one simple scenario of a use case. 
Well there you go: Next item to build the full scope might be the next scenario. (and so on.) This split pattern is called “Scenarios“. 
 

That is why you’ll find our deck of cards so useful. 
It can inspire and help you to see patterns of splitting you didn’t see before when negotiating towards scope reduction. 
Hopefully it will give you the courage to sit and collaborate till you have backlog items that have an level of predictability.