Progressive Story Splitting

Good stories are key to the success of software development for the vast majority of agile teams. Getting them right is not easy. We've found a way that works, and it's pretty simple!

Background

The INVEST model is widely accepted as an effective set of guidelines for ensuring your stories will be suitable for development. This article excellently explains what that means but in summary, stories should be:

I - Independent
N - Negotiable
V - Valuable
E - Estimable
S - Small
T - Testable

It is important to remember that these are guidelines and not rules, don't beat yourself up if your stories don't meet all of them.

Neil Killick recently blogged about one of the most important of these guidelines - that stories should be small. If you haven't already, I highly recommend you read what he has to say on it here.

Progressive Story Splitting (PSS)

PSS is a technique that I have developed with my team over the past few months. By doing it we have been able to maximise the amount of time we spend developing the right software while making sure that everyone collaborates in planning.

There are three stages to it...

Stage 1 - The Product Backlog

The product backlog is a list of features descending in priority order, with those the Product Owner would like to be developed sooner at the top. Each feature can be considered a story, but certainly doesn't have to be small. Given the potential for large stories, being estimable isn't necessary either.

In this example I'll pretend we're developing a flight booking website. Our product backlog may look like this:

1. Customer can search for a flight
2. Customer can book a flight
3. Customer can view flight details
4. Customer can view booking history
5. Administrator can add flights

Anyone should be able to suggest a story to be added to the product backlog. It is down to the Product Owner to manage it effectively.

Stage 2 - Create a high-level Story Map

Story Mapping was invented by Jeff Patton, the earliest mention of it that I can find is this article from 2005. The Story Map we're creating in PSS is a simpler version, concentrating on just one feature.

A Business Analyst, together with the Product Owner and the customer (or someone/some people that can represent the customer) will create a high-level Story Map.

Let's assume that the first feature on our product backlog has been developed and customers can already search for flights. We're going to create a Story Map for 'Customer can book a flight'. This should be done 1-2 weeks before it is intended that it will start to be developed.

Using sticky notes, the assembled group write down the functional tasks (in the form of stories) that will always be performed for a customer to book a flight. We've found that sticky notes are best as they can easily be moved around and/or discarded. Rather than sticking them directly onto the wall, join a few sheets of flip chart paper together and stick them onto that. This way it can be rolled up and moved elsewhere. The result may look something like this:

Click on image to enlarge

You'll notice that the first task has already been developed. It is useful to keep it on the map to give some context, I suggest using a different colour sticky note so that this is clear.

At this stage you should avoid saying how each task is performed. The group may have some thoughts on it, if so write them on the back of the sticky note if you'd like to capture them.

Next, the group will add tasks that will be performed often but not always. Place the new sticky notes on the next row down on your map, moving existing ones along so the sequential order is shown from left to right. If you have tasks that can occur at the same point in the process, place them above one another with the most frequently occurring one higher up.

Our map now looks like this:

Click on image to enlarge

Stage 3 - Collaboration

Up until now the rest of the team have been busy developing other stories, now is the time for them to get involved in planning. The next session will include all those who attended the last, with the developers and testers too, and will occur in the days leading up to development of the feature.

The Business Analyst will facilitate and start by talking the team through the map and any key points that have been discussed to date. The aim is to take the stories and split, merge, remove and replace them until the feature has been mapped into stories that are suitable for development.

Depending on the size of the original feature, this session can last anywhere from about 30 minutes to a couple of hours.

Up until now we haven't paid particular attention to the INVEST guidelines. With the developers and testers now contributing you can. They are best placed to ensure that each story is estimable, small and testable.

In our example questions that might be asked are 'What passenger details are entered?', 'What payment methods will be supported?', 'How will confirmation be sent to the customer?'. The customer or Product Owner should be able to give the team the answers and together, update the map.

Once the session is over, our map looks like this:

Click on image to enlarge

You may find that while discussing the stories you've established the acceptance criteria for each. While that's great, I recommend waiting until afterwards (still with the whole team though). We've found it more effective to establish the breadth of the feature before drilling down to the detail of each story. You can use the back of each sticky note to capture them.

What next?

If you're using Scrum, the Product Owner can now choose which stories will be candidates for the next sprint. This could include stories from a few maps that the team has created. With the team having been engaged in the planning process they can better select which stories they will include.

Additional tips

• If you do poker planning then you could write the poker points for each story on the corner of their sticky note
• As stories are completed change their sticky note to a different colour to indicate it

Conclusion

We've developed the PSS process using trial and error. We've taken wrong turns, learned from our mistakes and now find it just works. We find it hard to remember how we did things before!

Using PSS has given us the following advantages:

• The business end of our product backlog is visualised for everyone to see and understand
• The scope of a feature is understood by the whole team, including the Product Owner and customer
• There are less surprises, and if there are any it's relatively easy to walk up to a Story Map and replace stories or move things around

If you try this I'd love to hear about it, please use the comments section below. You can do the same if you have any questions, I'll try my best to answer any you may have.