Doing a story review

One of the changes we are doing on our process is that now more people will review the user stories before we start coding.

It's good to read.

It all starts with a problem that somebody has, this problem gets to the Product Manager who has to write it down so that the developer knows what he should fix. But because things can get complicated, details and context can be lost in this process, that's why it is a good idea to review this writing, to identify what the implicit and the explicit understanding is about.

Some time ago, I found a nice checklist to use when doing a story review.

What to question when doing a story review:

1. Is this story solving a problem?
2. If so, what is the problem we're trying to solve?
3. Could we implement a solution that doesn't solve the problem?
4. How will the story add value to the business?
5. Who are the end users of the feature?
6. What value will they get out of it?
7. What will users do, right before and right after they use that feature?
8. How do we know we're done with this story?

It came out from the Agile Testing book, by Lisa Crispin and Janet Gregory. If you think the list is good, I invite you to read the whole book.

The picture of astronauts reading comes from this page.