CPS 108 Project Retrospectives

Adapted from CPS 108, Fall 2000, by Robert Duvall

"Those that do not know history are doomed to repeat it."

It is important for each team member to take stock at the end of a project and review your project's history analyzing its positive and negative aspects. Typically such reviews are called post-project reviews or "post mortems." or retrospectives. The goal of a retrospective is to draw meaningful conclusions to help you learn from your past successes and failures. A retrospective is an extremely productive method of improving your development practices

For each project, you are to individually analyze your experience once you have turned it in and had a few hours to relax and reflect. Your analysis should include an honest, thoughtful evaluation of the progress of your team. Its aim should be to identify specific actions with the project that either helped or hurt later in the process. This document should not attempt to assign blame for failure. In most cases, the team as a whole should accept responsibility. Your retrospective may be due when your project is due, it may be due later; it's always due soon after finishing. The individual retrospective to your project should be submitted using an assignment name set up separately for each project. You may submit a text file, a web page, or a pdf file of your document --- in other words, do not feel you need to limit how you express yourself.

At least the following sections must be included in your analysis. Questions are provided to get you started thinking about what to consider within each section.

Don't be limited by these questions, but include them at least.

Project description
Begin the retrospective document with a brief overview of your project, including a design overview, estimated time spent on project, and project start and finish dates. Describe the product's purpose, intended customer, and other general information. This is intended to refresh your memory about the project when you read this analysis again later in the semester as well as let the course staff know what problem you thought you were solving.
Initial expectations
Document your initial thoughts about the project, including how hard you thought it might be, what you thought would be the easy and hard parts, and what specifications you thought were clear or ambiguous.
  
Current status
Document the quantifiable details of your project. Look over the entire project and document the purpose and invariants for each class used within the program. List everyone who worked on the project and document their role.
Did we have the right people assigned to all project roles?
Describe any early warning signs of problems that occurred later in the project?
How should you have reacted to these signs?
How can you be sure to notice these early warning signs next time?
Future work
No project is ever completely finished. Document at least five parts of your project that still need fixing, that you wish you could understand better, or could be extended or made more flexible.
What defect types occurred most frequently?
What defect types were most time-consuming?
What can you do to reduce the occurrence of those defects in your future projects?
Which parts required the most rework?
If you could work on one part right now to improve your grade, what would it be?
Lessons learned (both good and bad)
Document what went right with your project. List at least five things that met or beat your initial expectations for your project. Make a detailed list of your project's shortcomings. List at least five things that turned out worse than expected. Document unpleasant mid-project surprises as well.
Did you overestimate or underestimate the size of this project? By how much?
Did you overestimate or underestimate the time required for this project? By how much?
What does the difference in planned vs. actual size tell you about your design of the system? What problems were there in your design? How would you fix them?
What does the difference between planned vs. actual time tell you about the method you used to estimate time from size? What would you do differently next time?
Review your previous personal goals, did you meet them when working on this project?
 
Personal goals for later projects
It would be a great waste of time to create a beautiful project retrospective, archive it, and forget about it. You should develop an action plan that can be applied to your next project. Review your project history, reflect on the lessons you've learned, and specify new guidelines to follow in the future.

What conclusions can you draw from your project history that will help you improve in the future?
What should you start doing, keep doing, or stop doing?

Grading
Finally, based on your answers to the questions above, or the effort needed to discover the answers, what grade would you give the team's project? This is primarily intended to see if our assessment meets your expectations, not to influence your grade. Please note that it is rare that everyone in the course gets an A+.

Are you proud of our finished deliverables (project work products)? 
If yes, what's so good about them? 
If no, what's wrong with them?

Examples

Here are some examples of analysis' from other projects not related to this course. These examples are not endorsed in any way, but are meant to serve as an example.

Resources

Here are some other resources available online about project retrospectives/postmortems.

Owen L. Astrachan
Last modified: Tue Sep 18 22:29:18 EDT 2001