Requirements Retrospective

You are reading this book about a requirements process, presumably with the intention of improving your own process. Retrospectives are one of the most effective tools for discovering the good and bad of a process, and suggesting remedial action. Retrospectives for requirements projects consist of a series of interviews with stakeholders and group sessions with the developers. The intention is to canvas all the people involved in the process and ask tough questions:

• What did we do right?

• What did we do wrong?

• If we had to do it again, what would you do differently?

By looking for honest answers to these questions, you give yourself the best chance of improving your process. The idea is very simple: Do more of what works and less of what doesn't.

"if we did the project again tomorrow, what would we do differently?"

Keep a record of the lessons learned from your retrospective. The next project can then use that record as a starting point, so the lessons learned from previous projects are passed along.

Your retrospective can be very informal: a coffee-time meeting with the project group, or the project leader collecting e-mail messages from the participants. Alternatively, if the stakes are higher, it can be formalized to the point where it is run by an outside facilitator who canvases the participants, both individually and as a group, and publishes a retrospective report.

The most notable feature of retrospectives is this: Companies that regularly conduct retrospectives consistently report significant improvements in their processes. Retrospectives are probably the cheapest investment you can make in your own process.