Agile Software Development

The Two Ways to Add Detail to User Stories

Two roads diverged in a yellow wood—surely Robert Frost was talking about user stories. He was inevitably describing how there are two potential ways to flesh out user stories, and you need to decide which is right. Luckily, in a post at Mountain Goat Software, Mike Cohn explains what these two methods are and when to use them.

A Fork in the Road

The first option is to split the story into sub-stories. Cohn uses a great example here, taking “As a user, I can log in through a social media account” as a starting point. This story can be easily divided into sub-stories pertaining to specific types of social media (like Facebook) which with to log in.

The second option to provide detail to a user story is to add acceptance criteria. In the case of the social media example, the result would look largely the same as with the first option. You would add acceptance criteria that read something like “Can log in through Facebook” and “Can log in through Instagram.”

Cohn elaborates on when you would want to use one approach over the other. He provides two reasons for why you would want to use sub-stories. The first reason is that a story is just too large as is, making breaking it up the only practical option. Here is the other reason:

A second reason to split a story into sub-stories rather than adding acceptance criteria is when the acceptance criteria would be prioritized differently by the product owner.

In the case of logging in through social media, suppose the product owner said logging in through LinkedIn was a much higher priority than logging in through Facebook or Twitter. We wouldn’t want one story then that listed all three social networks as acceptance criteria. Instead we’d have one story about logging in through LinkedIn and one or two stories about Facebook and Twitter, depending on whether supporting each of them were of an equivalent priority.

Thus, Cohn segues into saying that the right time to use acceptance criteria is when (1) acceptance criteria are of roughly equivalent priority, and (2) the presence of acceptance criteria does not make it too big to include in a sprint.

For additional examples that elaborate the value of these two approaches, you can view the original post here:

Show More

We use cookies on our website

We use cookies to give you the best user experience. Please confirm, if you accept our tracking cookies. You can also decline the tracking, so you can continue to visit our website without any data sent to third party services.