Postmortem Report

Postmortem Review Meeting Information

Internal Release Number: X.Y.Z
Location of Meeting: LOCATION, BUILDING, ROOM
Date and Time of Meeting: YYYY-MM-DD HH:MM
Process Impact: This postmortem report summarizes the successes and failures of this project, lessons learned, reusable project bi-products, and recommendations for future process improvement. It is written as a joint effort by all team members, and read by (some of the same) team members when working on future projects.


What are the goals of this postmortem report?
The main goal is to create recommendations for software process improvement. Improving the process requires reflection on the history of the project and introspection into the team members' goals, ambitions, talents, and skills.
A second goal is to record and publish data that can be used in estimating the effort needed for future tasks and projects. Also, the bi-products of this project must be explicitly identified so that they may be tracked as organizational assets.
Another goal is to encourage team members to thoughtfully reflect on the project and officially record their comments. This is a satisfying activity for team members who are serious about improving the software development process and refining their own professional opinions.
What are the most important points of this postmortem report?
Training and team communications take a lot of time. We were behind schedule almost from the start of the project because the schedule did not include the needed training time. We recommend better assessments of training needs and better training plans in future projects.
It is better to have many small releases and allow problematic features to slip to the next release, rather than extend the schedule for a single release. We found that this release cycle was too long and too much integration work was needed at the end.
More complete requirements would have really helped us do more useful testing sooner.

Objective Evaluation of Project Performance

TODO: Gather and compare the following objective data on the project. Study status reports, review reports, the risk management worksheet and issue tracker items to find relevant metrics. Share this information with postmortem meeting participants.
Parameter Planned Actual
Total hours of effort 397 519
Delivery date 2004-12-01 2004-12-20
Features implemented All essential and expected All essential, most expected
Lines of code (KLOC) 30 41
Number of tracked defects 300 380
Number of release candidates needed 2 3

Team Member Survey

TODO: Ask each postmortem review participant to (anonymously) rate the project on each of the following criteria. Enter the count in each cell below. These criteria are samples, adjust them to fit your process improvement goals. Ask the team about the best and the worst aspects of this project. Review your software development methodology document to identify additional evaluation criteria.
Evaluation Criteria Much Better Better As Expected Worse Much Worse
Product's benefit to customers 00000
Product's quality 00000
Our productivity 00000
Our teamwork 00000
Effectiveness of tools used 00000
Value of requirements document 00000
Value of design document 00000
Effectiveness of reused components 00000
Generation of new reusable components 00000

Team Member Quotes

TODO: Capture any comments that team members want to make "on the record." These quotes may be anonymous if desired. Suggested prompts: what went best? what went worst? what would you personally like to do better next time?

It may have been easy enough for the QA team to enter defect reports, but we [developers] had a hard time reproducing the failures. --Anonymous

We need to cross-train our developers so that at least two people understand each component. --PERSON-NAME

The UI screen design and use cases really worked well together. --PERSON-NAME

This is the last release that we should expect the QA team to do much ad-hoc testing because that did not work well. --PERSON-NAME

Valuable Bi-Products

In addition to the planned deliverables, this project also produced the following reusable components, utilities, and documents that could be valuable to other projects.

  • xyz2abc: Data file conversion utility for .XYZ files
  • libtax: Library for sales tax computations
  • server-request.txt: Document template for accurately requesting that a new server be set up
  • Installed new division-wide version control server
  • Improved test design process
  • UTILITY-NAME: Utility for PURPOSE.
  • LIBRARY-NAME: Reusable library for PURPOSE.
  • TEMPLATE-NAME: Document template for PROCESS-STEP
  • INFRASTRUCTURE-CONTRIBUTION: Reusable server or software setup
  • SOFTWARE-PROCESS-IMPROVEMENT: Changes to software development methodology

Lessons Learned and Recommendations

What general lessons have been learned from this release?
Next time, we need to order needed hardware sooner and walk the purchase through our purchasing department to avoid downstream delays.
What technology selection lessons have been learned from this release?
What quality assurance lessons have been learned from this release?
We should start testing sooner.
Having a developer available to the QA team would really have helped us overcome some early hurdles.
What PROCESS-ASPECT lessons have been learned from this release?
We need to make sure that any major refactoring is done only after a team discussion of its impact.
What additional items should be added to the release checklist?
What additional items should be added to the templates for project planning or QA planning?
What changes should be made to the software development methodology?
What additional items should be added to the other templates?
TODO: Check for words of wisdom for additional advice on this template.
Company Proprietary
Copyright © 2003-2004 Method Labs. All rights reserved. License terms. Retain this copyright statement whenever this file is used as a template.