Correct way to break feature into user stories

Question

I've been questioning the size of the user stories that i'm currently working on. The feature that i am implementing is a Datepicker component. The business value of the component is to allow users to quickly choose a date range. The component will be used on multiple pages of the web application.

Currently, there are three user stories to describe this feature:

• View two months at a time
• Click arrows to scroll through displayed months
• Highlight selected date range

My argument is that, none of the user stories are worth anything by themselves and that they are too "horizontal". A more "vertical" approach would involve a single user story of "Datepicker component" which encapsulates the behaviour of the current 3 user stories.

Am i correct in thinking that a more vertical approach is a better idea?

Answer 1

A more "vertical" approach is the common guidance on splitting stories. What it reinforces is:

• A multi-functional team capable of working on the whole product
• Building a dirt road and then adding features to it
• Keeping the portion of an added feature useful to the end user

However, what I don't have a good answer for is that typically there is some prep work involved for the dirt road. To stay "in metaphor", you have to clear the path and make a level surface. That kind of gets merged into the first story being built. After that the additional pieces go quickly, but the prep work is hard to account for properly. On its own it adds no direct value to the user, but it is necessary to make way for the new feature set.

In this example, you might start with the simplest thing:

• Display 1 month
• Highlight selected date range

The next story would be:

• Display second month

Finally,

• Add scroll forward and scroll backward for the displayed months

With this example, the user has something minimally useful from the first implementation. The next story is primarily UI related since you might have to rearrange controls to present the months side by side. If you haven't already made the month view it's own display component, you know you have to do that now. Finally, the ability to scroll back and forward will end up being more of back end changes.

This is just an example of how to do it in this case. Just think of what the minimal viable solution would be for the first story, and with each successive story you are making the application more and more useful.

Answer 2

I don't agree that the stories you presented are sliced horizontally. With horizontal slicing, you see stories that are targeted at different disciplines within the team or stories that don't offer any functionality to the user until the complete feature is done.

If you have vertically sliced stories, then each story offers something to the user, even if the story does not offer enough to satisfy the need of the user. In that sense, your stories look like vertical slices to me, although different vertical slices could also be made (like the slices shown by @Berin in his answer).

With regard to merging them into a single story, that should only be considered if the story for the "complete DatePicker component" is small enough to be easily completed in a single sprint.

Answer 3

Here's the trouble I have with the user stories you list: it seems like there is an exact implementation in mind and someone is trying to write user stories around that. That isn't the point or benefit of user stories. User stories should be written with the user need in mind. Something like:

As a meeting organizer, I'd like to be able to pick a date off a calendar because sometimes I know it's the third Saturday, but I don't know the date.

and then onto that:

As a meeting organizer, I'd like to be able to switch months I'm looking at so that I can plan further out than this month.