Postmortem Report
Postmortem Review Meeting Information
| Project: |
PROJECT-NAME |
| Internal Release Number: |
X.Y.Z |
| Location of Meeting: |
LOCATION, BUILDING, ROOM |
| Date and Time of Meeting: |
YYYY-MM-DD HH:MM |
| Attendees: |
PERSON-NAME
PERSON-NAME
PERSON-NAME
PERSON-NAME
|
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.
Introduction
- 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 |
0 | 0 | 0 | 0 | 0 |
| Product's quality |
0 | 0 | 0 | 0 | 0 |
| Our productivity |
0 | 0 | 0 | 0 | 0 |
| Our teamwork |
0 | 0 | 0 | 0 | 0 |
| Effectiveness of tools used |
0 | 0 | 0 | 0 | 0 |
| Value of requirements document |
0 | 0 | 0 | 0 | 0 |
| Value of design document |
0 | 0 | 0 | 0 | 0 |
| Effectiveness of reused components |
0 | 0 | 0 | 0 | 0 |
| Generation of new reusable components |
0 | 0 | 0 | 0 | 0 |
| EVALUATION-CRITERIA |
0 | 0 | 0 | 0 | 0 |
| EVALUATION-CRITERIA |
0 | 0 | 0 | 0 | 0 |
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.
- COMMENTS
- What technology selection lessons have been learned from this release?
- COMMENTS
- 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.
- COMMENTS
- 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.
- COMMENTS
- What additional items should be added to the release checklist?
- COMMENTS
- What additional items should be added to the templates for
project planning or QA planning?
- COMMENTS
- What changes should be made to the software development methodology?
- COMMENTS
- What additional items should be added to the other templates?
- COMMENTS