Working iteratively to deliver working software incrementally needs a different approach to requirement gathering. This chapter looks at the approach most commonly combined with Scrum: the User Story.

We'll start by briefly looking at why traditional requirements documents don't fit well with an incremental approach. We'll then contrast this with User Stories and how they work to solve some of those problems.

We'll then take a practical approach, using a cinema ticket booking system as an example, to gradually build up a User Story, considering the various elements that contribute to making this technique powerful. 

After we've built up a good understanding of User Stories and Agile's requirements, we'll look at how to use relative sizing, an Agile alternative to estimation.  We'll use a game called Planning Poker to show how estimation can be easy and fun while teasing out all the important details of what we're about to build.

This chapter covers the following topics:

• The pitfalls of traditional big upfront requirements
• Why User Stories produce better results
• What a User Story is and how to use it
• Card, conversation, confirmation
• Acceptance criteria versus the Definition of Done (DoD)
• Telling the team the what, not the how
• Estimating Agile user requirements