Monday , December 18 2017
Home / Agile Software Development / The Two Ways to Add Detail to User Stories

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:

About John Friscia

John Friscia is the Editor of Computer Aid’s Accelerating IT Success. He began working for Computer Aid, Inc. in 2013 and continues to provide graphic design support for AITS. He graduated summa cum laude from Shippensburg University with a B.A. in English.

Check Also

Do Scrum Teams Meet Too Much?

From a distance, it sounds like scrum has a lot of meetings. Heck, you have …

Leave a Reply

Your email address will not be published. Required fields are marked *