Slicing User Stories

Question

I have few queries on how granular we need to go on splitting stories.

We have a story where clicking the phone no in the system should dial cisco or skype or any other telephony systems based on the user environment.

My query is if using INVEST, this should be 3 different user stories - one for each telephonic users. Technically, Dev might be using the same function to call based on individual configurations; so is it okay where dev use the same function or write same code to deliver these multiple functions be combined in a single story.

In case, when we split them in multiple stories, there might be a situation where related user stories might be missed out in a sprint. Can we have a practice like after pulling the master user story in the sprint, we again split them into 3 separate stories in the Sprint Planning session.

Please give your inputs.

Answer 1

The short version is that it is the development team's decision. Let's say you have this story:

As a user with a telephone program installed, I want to automatically dial a number when I client on it in the application so I don't have to remember the phone number and key it in.

As a product owner, that encompasses the user's need perfectly, so I'm going to take that to the development team - probably during backlog refinement (or grooming - two names for the same thing). Now, the team will either say "Yes, that seems like it is small enough to fit into a sprint, let's leave it as one story." or they may say "No, that's too big." At this point, the team and PO must have a discussion to find a balance - what slice is small enough and still delivers value. Maybe it's something like you said:

As a skype user, I want to be able to click on a telephone number ...

Now, you could go ahead and split the others out, but I wouldn't right away. It may be that once they do the first one, all of the rest can be done together. Or, the team may decide to just take it one at a time. That's mostly their decision. On the other hand, looking at them as pieces may create a conversation where the PO decides that some options just aren't that valuable. There isn't a right answer here - just finding a balance through collaboration.

With this approach, we keep the big picture in mind and focus on the details as they come.

Answer 2

How granular we need to go on splitting stories?

You need to break down as much as you can so that you can deliver the Story within the iteration.

Based on my experience, if there's a functionality that'll have a "framework" to be used for other similar functionalities (the master story you mention) then you have to decide whether:

• it's better to work on them all at the same time (same iteration) and that all of them can be delivered as a single feature OR
• it's better to have the story delivered for a specific case, validated by users and then implement the "related" stories

This decision is strongly dependent on the business you're working on and the team you have. Another aspect sometimes overlooked is the duration of your iterations - sometimes it's better to have larger iterations and deliver more well finished stories rather than break them down to fit smaller iterations.

Remarks when splitting user stories:

• Do not break them down by layers (front end / backend) or technologies. A Story should be fully functional when delivered. You may have tasks written as stories. Avoid them. A task completed (a frontend, for instance) is very unlikely to add any business value.
• Do not break them down alone. Story breakdown should be done by PO and team, together, with a clear purpose.
• Do not try to deliver all possible scenarios at once. Prioritise the happy path. Confirm it delivers the value expected. Create new stories for handling exception paths.