A Retrospective on Retrospectives

Mark BullockQA Engineer
If you are using Scrum Framework or another agile process, a retrospective may be part of it. Does your team perform retrospectives? Are you getting value from your retrospectives?

I see a common anti-pattern when people conduct a retrospective for a sprint or write a root cause analysis for a defect. First they will point out the sequence of events that led to some code executing which caused the wrong thing to occur. Then to prevent that kind of problem from happening in the future they will basically conclude "we will try harder" or "we won't do that next time."

The purpose of a retrospective is to improve your process continuously. First identify something that didn't go well; perhaps it's a defect. Next your team must examine each step of the process which resulted in the defect. For each step think about whether the defect got created in that step and whether the defect escaped detection in that step. Finally, decide what actions to take to improve your process.

For the scrum framework process, you might think about the following.
  1. Did you groom the story in the backlog before adding it to the sprint?
  2. Was the story too big?
  3. Did you rush to finish the story to make the sprint deadline?
  4. Were the acceptance criteria sufficient?
  5. Were the acceptance criteria specific?
  6. Did you write the acceptance criteria together or review them?
  7. Did you add acceptance criteria during the sprint instead of putting them on the backlog?
  8. Did you do Test Driven Development?
  9. Were there sufficient automated unit, integration, and acceptance tests?
  10. If you refactored, did you have sufficient automated tests in place before refactoring the code?
  11. Did you demo the story with all of the acceptance criteria?
In addition to retrospectives for each sprint, you may also want to have a retrospective at the end of a project. You can consider additional things such as:
  • Do you need to add backlog items to fix usability, performance or functional issues?
  • Did the rollout go smoothly?
  • Did you have a user story for the rollout?
  • Were you able to measure or demonstrate the business value of the project?
If you examine your process you can improve it. If you don't you won't and isn't that insanity?
Mark BullockQA Engineer

Comments (0)

Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.