A Little Book about Requirements and User Stories: Heuristics for Requirements in an Agile World

By Allan Kelly

"I'd highly recommend this book for those who are starting an agile or lean transformation, so as to avoid bad starts and the related frustration." Amazon Review - DLed

"The information is very useful and well explained. It is just what pretends to be - gives full understanding on the topic. I recommend. It is not the deepest and detailed book for user stories, but gives plenty of important information. For starters in working in typical agile process environment is must have." Amazon Review - Steff

"I love the way Allan can explain complex stuff in simple ways and giving examples. I have took some important intention here that I can apply right away. Love it" Amazon Review - Wilson Govindji

 

"How do I make my user stories smaller?"

"What is the right size for a user story?"

"What is the difference between an Epic and a Story? And where do Tasks and Sub-tasks fit in?"

"Who writes user stories?"

"Why user stories?"

"Do I have to use User Stories?"

Allan Kelly found himself answering these questions, and similar ones, again and again so… he sat down to write the answers and this book was born.

In this book Allan discusses the role of user stories: they are not requirements, they are tokens for work to be done and a placeholder for a conversation. He gives his two golden rules: stories must be small and they must be beneficial to the business - further he describes what beneficial is, how to put a value on a story and how to maximise the return on investment.

He gives particular attention to the difference between requirements and specification and how these ideas line up with user stories and acceptance criteria. Along the way he takes epics, tasks, definition of done, backlog structuring, acceptance tests and much else.

In short, its little book about user stories and all that goes with them.

Having used user stories in daily work for a couple of years, I must say, had I read this book earlier, hours of futile discussions and weeks of failed attempts to get user stories and the process around them right.

The book touches upon many common pitfalls in communication that might undermine the overall success of the team. Every important aspect of software development is tackled, based on perceivable experience of the author.
 

• Language: English
• Publisher: Software Strategy Ltd.
• Release date: Oct 5, 2017
• ISBN: 9780993325052

Book preview

A Little Book about Requirements and User Stories

A Little Book about Requirements and User Stories

Heuristics for requirements in an agile world

Allan Kelly

This book is for sale at http://leanpub.com/userstories

This version was published on 2017-04-04

publisher's logo

*   *   *   *   *

This is a Leanpub book. Leanpub empowers authors and publishers with the Lean Publishing process. Lean Publishing is the act of publishing an in-progress ebook using lightweight tools and many iterations to get reader feedback, pivot until you have the right book and build traction once you do.

*   *   *   *   *

© 2015 - 2017 Allan Kelly

ISBN for EPUB version: 978-0-9933250-4-5

ISBN for MOBI version: 978-0-9933250-3-8

Table of Contents

About the author

1. Conversation and benefit

A Placeholder for a Conversation

Each Story Has Business Benefit

2. Small and beneficial

A Balancing Act

How Small Is Small?

So, What’s the Right Size?

Practice Makes Progress

3. Assessing the Business Value of Agile User Stories

Calculating Business Value

Assessing Cost Savings

Time as a Business Factor

The Importance of a Company Strategy

4. As a Who?

As a User? You Can Do Better!

Roles, Personas, and Stakeholders

Don’t Write Stories about the Team

Are systems roles?

Conversation forgives and resolves

5. Stories, Epics, and Tasks

Stories up and down

Go Large with Epics

Go Small with Tasks

Three Organizational Levels

Color Coding and Planning

Making Use of Your Choices

6. Defining Acceptance Criteria

Acceptance Criteria and Testers

The Level of Detail

The Right Time to Define

Acceptance Criteria in Action

7. Acceptance Criteria, Specifications, and Tests

Splitting Stories by Acceptance Criteria

Specifications and Tests

Specification by Example

Test Automation: More Than Fast

8. Definition of Done

Acceptance Criteria or Definition of Done?

Task Twist

Working within Columns

Reviewing and Updating the Definition

9. Working with Nonfunctional Requirements

Nonfunctional User Stories

Specifying the Requirements

Constraints and Value

Opportunities to Benefit

10. Stakeholders

Seeking Out the Real Benefit

Evaluation: Closing the Loop

11. Estimating Business Value

Estimating the Business Value

The Result: Prioritization and Conversation

12. Effects of Time on Value

Value before Estimates

Engineer within Constraints

The Cost of Delay

Time, Value, and Risk

13. Maximising return on investment

More to Modeling and Calculating ROI

Value-Based Prioritization

Next Stop: Continuous Delivery

Story by Story

14. Writing stories - where do I begin?

Solo brainstorm

Group brainstorm

Write as you visit

Big requirements doc

Work continues

15. Backlog structure

Two backlogs good

Three backlogs better

Finally

16. Alternatives

Stories, PBIs, JBTD, etc. etc.

Use cases

Persona stories

Finally

17. Last words of advice

Keep them Short

Break, don’t bend, the format

So that

Context is important

Not an analysis technique

Appendix: Requirements and Specifications

Specifications

An example

Enter the Iteration

And tests

Automated acceptance tests: the new formal methods

Knowledge and Trust

Conclusion

References

Quick User Stories FAQ

What is the right size for a User Story?

When is the conversation?

How do I determine business value?

How do I make my User Stories smaller?

When do I use a Story and when do I use and Epic?

How big should my backlog be before we start coding?

How do I write strong User Stories?

When is a User Story ready to go to development?

Acknowledgements and history

History

Notes

About the author

Allan Kelly has held just about every job in IT. London-based, he works for Software Strategy, where he provides training and consultancy in Agile practices. He specialises in working with software product companies, aligning company strategy with products and processes.

He wrote his first program at the age of 12 on a Sinclair ZX81, in Basic. He quickly progressed beyond the ZX81 and spent the mid-80’s programming the BBC Micro in BBC Basic, 6502 Assembler, Pascal and Forth. As well as appearing in several hobbyist magazines of the time, he was a regular on BBC Telesoftware, with programs such as Printer Dump Program (PDP and PDR), Eclipse, Snapshot, Echos, Fonts, FEMCOMS and, with David Halligan, Demon’s Tomb, and EMACS (Envelop Manipulation and Control System, nothing to do with its more famous namesake!).

In addition to numerous journal articles and conference presentations, he is the author of Business Patterns for Software Developers (2012) and Changing Software Development: Learning to be Agile (2008), both published by John Wiley & Sons, and Xanpan: Team Centric Agile Software Development (available on LeanPub, Lulu and Amazon in eBook and printed versions). He is also the originator of Retrospective Dialogue Sheets (www.dialoguesheets.com).

More about Allan at http://www.allankelly.net and on Twitter as @allankellynet.

Xanpan: Team Centric Agile Software Development

Xanpan: Team Centric Agile Software Development

Business Patterns for Software Developers Business Patterns for Software Developers

Changing Software Development: Learning to Be Agile

Changing Software Development: Learning to Be Agile

1. Conversation and benefit

User stories are probably the most widely used requirements technique in the agile world. This humble little who-what-why template was originally devised in 2001 by a team at Connextra in London, and it quickly gained widespread adoption:

As a someone I want to do something So that some result or benefit

Simple, really.

Many traditional requirements engineering and elicitation techniques are still valid in agile; it’s just the results don’t end up in a big document. Agile emphasizes just-in-time requirements rather than upfront preparation. The requirements person—be it the product owner, business analyst, product manager, or someone else—embodies the understanding of what is needed, and the user story represents the work that needs doing.

User stories have three attributes that fit well within agile:

Lightweight: They don’t impose a lot of (upfront) costs on the team

Easy to understand: You don’t need a five-day course to understand them

Easy to share: Objectives are simple to communicate between the technical team and customers

It is the third of these attributes that makes user stories my preferred choice: they are inclusive. Customers can engage with stories. Many other techniques are superior in terms of analysis, rigor, and completeness. But these advantages come at a significant cost: They create a barrier between those skilled in the approach (technical experts) and those who are not (customers.) Because user stories are so simple, they help create common understanding.

An early User Story shown to the world by Rachel Davies and Tim MacKinnon at the XP 2001

(Thanks to Rachel for sharing.)

A Placeholder for a Conversation

User stories are not, and should not be, complete requirements for software development. People call user stories a placeholder for a conversation, meaning the stories capture the essence of what is wanted, but they don’t contain the detail. When the time comes to do the work, there will be a discussion about what the stories need.

I think of stories as tokens for work to be done. They are not the work itself—that has not yet been defined—but they represent the work. These tokens can be prioritized, shuffled, refined, changed, split, and more. When a token rises to the top of the pile, it is time to work on the story.

The first job is to understand what the job is. Conversations about stories are not just between the requirements person and the coder. If the team contains software testers, include them, too. Indeed, having the tester in the conversation is more important than having the coder.

User stories themselves need not be perfect; in fact, the biggest mistake with user stories is trying to make them exactly that. They should be transitory and short-lived: a means to an end, not the end itself.

When it is time to have that conversation, try conducting it in person instead of through documentation. Written documents are more expensive than commonly recognized. Each document costs twice: writing time plus reading time. There are other more effective, more efficient forms of communication.

Having a conversation about a piece of work can be cheaper, timelier, and more effective than communicating via documents or email. In a conversation, people can ask questions, skip a section, or discuss a section in depth. So, save time (and money) by talking instead of writing documents.

Each Story Has Business Benefit

Each story should have some business value. The story may earn revenue, reduce costs, attract customers, make employees more effective, or deliver value in some other way. Putting a value on a story may require sales projections or an