In an earlier post, I announce my latest book project, Agile Requirements: Lean Requirements Practices for Teams, Programs and the Enterprise, and noted that I’d be sending out snippets for review (and hopefully use by others) during the project. Of course, you can’t write about agile requirements without writing about user stories, and although I’ve blogged a bit on this topic in the past, I’ve never taken the time to describe them in the depth that would be appropriate for the book. While writing the chapter, Pete Behrens (a friend and Certified Scrum Trainer) decided to dive in with me and co-author that Chapter.
We thought it might be useful to others, so we’ve published it whitepaper form: User Story Primer_1
You can also find it on the Resource page.
Comments are always welcome.
Scaling Software Agility 
That is one of the best written and most useful documents I’ve read in a long time. Thanks for sharing Dean.
Clarke
Thank you for the primer! this is a very useful document.
Hi Dean,
Overall, a great document. Some comments, hope they are perceived as constructive. We have debated some of these, would enjoy seeing an outside opinion:
Page 4
User Stories are…
“- They are short and easy to read, understandable to developers, stakeholders, and users”
But as per the next section, a User Story == Card + Conversation + Acceptance. In our cases, the conversation gets quite technical and lengthy. Seems like he means just the Card part of users stories are short and easy to read?
User Stories are…
“- They are short and easy to read, understandable to developers, stakeholders, and users
– They represent small increments of valued functionality, that can be developed in a
period of days to weeks”
Another issue we have hit is sometimes a one liner from a user (send a text message via a proprietary tech stack) is a 3 month dev effort. We revert to System Stories here. See also vertical slice comment below.
User Stories are…
“- They need little or no maintenance and can be safely discarded after implementation
– User stories, and the code that is created quickly thereafter, serve as inputs to
documentation, which is then developed incrementally as well”
Seems to be a problem, how to write documentation from user stories if user stories are discarded “after implementation”? May mean “after release”?
Page 6
“We call this the “user voice” form of user story expression”
Sometimes the “user” is another system. We have had long debates about these, would be good to address. Some claim a User Story isn’t valid unless there is an actual user (human) there. But when building a product that contains APIs for a customer specific external system to call, we don’t have a way to know how an actual end user (human) will trigger invocation. In those cases, the role is “external system A”. You could then argue that the role is “our internal test framework”, but since we never ship our test framework it isn’t a valid role for a user story. Since we have talked about this quite a bit, would really like to see this covered.
Page 8
“helps teams achieve predictability. The lack of overly constraining and too-detailed requirements enhances the teams and businesses ability to make tradeoffs between functionality and delivery dates. Because each story has flexibility,”
Would be nice to address how this relates to estimates here. If tradeoffs are being made mid-implementation, estimates will suffer. Isn’t this bad?
“Creating valuable stories requires us to re-orient our functional breakdown structures from a horizontal to
a vertical approach.”
Similar to the proprietary text message situation above – how to make a user story BOTH small AND deep? What if there are 10 layers of technology required to implement that vertical slice? One approach would be to fake out the bottom 7 layers for the first story, and then iterate down in later stories. Is this the recommended approach? In our case, faking out layers doesn’t deliver value, because the product only delivers value if all 10 layers are working (from user interface all the way down to a device on the home area network).
Peter
Peter,
Wow, thanks for the detailed feedback. My responses are below.
“Seems like he means just the Card part of users stories are short and easy to read?”
[DAL} Agreed. I meant that the card part is short and easy to read and discuss. The acceptance criteria can be another matter entirely.
“Another issue we have hit is sometimes a one liner from a user (send a text message via a proprietary tech stack) is a 3 month dev effort. “
[dal] true, short and easy to read doesn’t mean easy to implement. But I’d still rather have a short statement that implies a lot of work that the team has to figure out, than an elaborate SRS that implies lots of work but is overly constraining.
“Seems to be a problem, how to write documentation from user stories if user stories are discarded “after implementation”? May mean “after release”?
[dal] I assume that the documentation is developed as the iterations progress. Doc people see the code, get their hands on the system, and document as they go. Plus you don’t HAVE to throw the stories away, and in all likelihood they persist in the project management tool indefinitely and they can be used for reference purposes. But we don’t have to maintain them and we could throw them away (but not the acceptance criteria/acceptance test that we use to validate them. ]The point is that there are shallow, imprecise and transient, so we don’t create a work project to keep them up to date as retrospective documentation.
“We call this the “user voice” form of user story expression”
Sometimes the “user” is another system. We have had long debates about these, would be good to address.
[dal} I for one, am pretty confortable when the user is another system and I see it all the time. In some larger systems of systems, most of the time the user is another system. This is a parallel with use cases, where an actor can be a user, device, or other system. Just don’t forget the ultimate, end user value that “brought you here”.
Page 8
The lack of overly constraining and too-detailed requirements enhances the teams and businesses ability to make tradeoffs between functionality and delivery dates.,”
Would be nice to address how this relates to estimates here. If tradeoffs are being made mid-implementation, estimates will suffer. Isn’t this bad?
[dal] tradeoffs are always being made mid-implementaion and estimates are always changing. It isn’t bad, it’s just reality. Team velocity and its “law of large numbers’ (averaging stories over time should) still track though.
Similar to the situation above – how to make a user story BOTH small AND deep? What if there are 10 layers of technology required to implement that vertical slice? One approach would be to fake out the bottom 7 layers for the first story, and then iterate down in later stories. Is this the recommended approach?
[dal] two thoughts 1) faking the layers does bring value to the team if you can stub or mock object the other layers to get a portion of the value stream working in a short timebox. 2) While this chapter is about user stories, if I had a story as broad and deep as you describe, touching ten layers, then I’d use a use case, not a user story, to elaborate all those actors and system interactions, and then split the use case into stories for implementation. The value stream is not lost – it’s carried by the parent use case. That will be in another chapter.
The larger caution is this. The whitepaper is written from a pure method and abstract perspective and as such is never limited by the real world. It’s just words on paper and all the examples conform so nicely to the points the writer is trying to make. However, real world projects have real issues are and the types of things you describe are all ensible to me. But “remember the value stream…”.
— Dean
Dean – thanks for taking the time to follow up. I appreciate the answers! This is a helpful resource.