Our review manifesto reflects our approach to internal project review meetings. The purpose is to provide all team members with a clear understanding and structure of how the perfect review meeting should be.
Rule number one: Keep it positive.
1. Prepare for the Review:
- Test: It’s not a group bug fixing round. Test everything first!
- Finish: Team members present finished work. If it’s not finished, it’s not being reviewed.
- Prepare: The staging server has all work that should be reviewed. It has all of the needed data, on the correct pages, and with the correct content.
- Reflect: Think about things that went really well or turned out very good and think about things that could be improved.
- Feedback: The team looks at the newly finished work and gives positive feedback. What looks really good? Which decision worked out very well? What element is so good and should we also use for other components.
- Improve: The team looks at the newly finished work and asks: “How can we make this even better?” When pointing out improvements, try to be supportive.
- Don’t Dive Deep: Like a stand-up, the discussions don’t have to go into depth if it does not concern all team members, or if the assignee can take care of the issue themselves.
- Goals: Establish clear goals for what should be completed for the next review.
- Blockers: Establish if there are any ‘blockers’ that need to be taken care of (e.g. missing assets or questions the client should answer).
- Issues: The team should discuss what is unfinished and if anyone is having difficulties or can’t make their deadline.
- Schedule: Schedule the next review meeting and be sure everyone knows what should be done by then.
- Each developer is responsible for taking their own notes from the review and implementing the discussed improvements before the next review.
- Make every effort to keep the meeting positive.
And remember to be positive.