On This Page

A Free PDF to Help You Choose the Approach

A Free PDF to Help You Choose the Approach

I’ve created a PDF you can download that will help you decide which approach is best for any story you’re adding detail to. It also includes examples of the two approaches.

Download my PDF
This article has an audio version:    Download Audio Version

A common question I get is how can a product owner (or team) be sure they've thought of everything when writing a product backlog. The question is especially common from teams doing contract development where an upfront requirements specification is still expected. But I also get the question from teams in organizations that like to unnecessarily lock everything down way up front.

I've given this a great deal of thought and I've finally figured it out. Here's how you can be sure you've thought of everything when writing a product backlog:

Wait.

Yes, wait until the end of the project. The only way to be sure you've thought of everything is to dive in, complete the project, get to the end and over time learn exactly what it was your customer wanted.

Every non-trivial project includes some emergent requirements. An emergent requirement is one that was not known in advance but that the customer figures out sometime during the project. No matter how hard a customer or product owner is asked to think, they will always come up with new requirements during the project. These result from looking at, and even better, touching, the system being built. Seeing what has been developed gives users new ideas. "Now that I've seen it, here are some new things I want," they tell us.

Customers and product owners should not use the existence of emergent requirements as an excuse for shoddy thinking. Development teams have the right to expect them to make reasonable efforts at knowing what they will eventually want. But, just as product owners and customers cannot possibly know everything in advance, development teams need to stop expecting them to.

Certainty is impossible. Avoid asking for or expecting it.

Mike Cohn

About the Author

Mike Cohn specializes in helping companies adopt and improve their use of agile processes and techniques to build extremely high-performance teams. He is the author of User Stories Applied for Agile Software Development, Agile Estimating and Planning, and Succeeding with Agile as well as the Better User Stories video course. Mike is a founding member of the Agile Alliance and Scrum Alliance and can be reached at hello@mountaingoatsoftware.com. If you want to succeed with agile, you can also have Mike email you a short tip each week.