5

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?

Improve this question
5
  • 1
    The correct way would be to write your user stories from the system level instead of the "DatePicker" level. It may turn out that you'll need to be more specific on what "DatePicker" needs to do after writing the system level user stories. If that's the case then write "DatePicker" specific stories derived from the system level stories. If you do write "DatePicker" specific user stories, since they are derived from the higher level user stories, then you'll find that you don't need to ask anyone because it will be obvious they are correct because they fall out naturally.
    – Dunk
    Commented Sep 29, 2017 at 18:23
  • @Dunk The process where i work has 2 levels above user stories - epics and features. Looking at the features they are typically written at the system level, I think that this could be the problem...
    – rssfrncs
    Commented Oct 2, 2017 at 10:41
  • @rssfncs - There are many ways to write user stories and almost all of them are fairly useless IMO. After countless iterations of approaches at writing stories (which I call use-cases because that's what I was trying to learn when I started writing them) the single most effective stories are written with one action per sentence. The sentence clearly says WHO does WHAT ACTION to WHOM. This leads directly to sequence diagrams and easy identification of domain classes/modules and their responsibilities. IME, every other way of writing stories doesn't provide enough payback for the effort
    – Dunk
    Commented Oct 2, 2017 at 13:31
  • ...And even that approach only works if you are very careful to leave implementation details out of the story. Think of the story and sentences as requirements and not design. Thus, database, GUI, buttons, controls and implementation things like that should never appear in the story.
    – Dunk
    Commented Oct 2, 2017 at 13:37
  • One last thought, I suppose that it is possible to make a "DatePicker" component have an extraordinary number of operations where user stories are helpful. However, from your description it seems like DatePicker is at such a low level as it is, that writing user-stories doesn't add value. Instead, it would be more useful to write down clear requirements and then write test cases for the DatePicker.
    – Dunk
    Commented Oct 2, 2017 at 13:43

3 Answers 3

Reset to default
6

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.

Improve this answer
4

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.

Improve this answer
0
4

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.

Improve this answer
1
  • I totally agree, in the process of my team however, there are 2 levels above user stories - epics and features. Looking at the features they are typically written in a similar style/pov to the examples you gave, I think that this could be the problem...
    – rssfrncs
    Commented Oct 2, 2017 at 10:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.