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.
