<

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x

A Retrospective on Retrospectives

Published on
3,790 Points
790 Views
Last Modified:
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?
0
0 Comments

Featured Post

Introduction to Web Design

Develop a strong foundation and understanding of web design by learning HTML, CSS, and additional tools to help you develop your own website.

With the power of JIRA, there's an unlimited number of ways you can customize it, use it and benefit from it. With that in mind, there's bound to be things that I wasn't able to cover in this course. With this summary we'll look at some places to go…
Starting up a Project

Keep in touch with Experts Exchange

Tech news and trends delivered to your inbox every month