From Fedora Project Wiki
(Try my hand at a post mortem template) |
No edit summary |
||
| Line 1: | Line 1: | ||
This template is used for teams conducting a post-release assessment of how successful they were at meeting their self-imposed set of deliverables on schedule and with community involvement. | This template is used for teams conducting a post-release assessment of how successful they were at meeting their self-imposed set of deliverables on schedule and with community involvement. | ||
== Things we did well == | |||
* Each person involved should state one thing the team did well, or improved substantially, during this release cycle over the previous one. | |||
== Things we did not do so well == | |||
* Each person involved should state one thing the team did not do well, or which may have regressed, during this release cycle compared to the previous one. | |||
== Deliverable assessments == | == Deliverable assessments == | ||
| Line 28: | Line 34: | ||
*** If not, consider whether there are enough people skilled and interested enough to finish a project to create the tools/services needed. Not every idea can be made into a reality without hands to do the work. | *** If not, consider whether there are enough people skilled and interested enough to finish a project to create the tools/services needed. Not every idea can be made into a reality without hands to do the work. | ||
** Would the new deliverable(s) replace/obsolete any existing deliverables? | ** Would the new deliverable(s) replace/obsolete any existing deliverables? | ||
[[Category:Marketing]] | |||
Latest revision as of 04:08, 14 March 2010
This template is used for teams conducting a post-release assessment of how successful they were at meeting their self-imposed set of deliverables on schedule and with community involvement.
Things we did well
- Each person involved should state one thing the team did well, or improved substantially, during this release cycle over the previous one.
Things we did not do so well
- Each person involved should state one thing the team did not do well, or which may have regressed, during this release cycle compared to the previous one.
Deliverable assessments
- Deliverable 1
- Was this deliverable finished on schedule?
- Does a repeatable process occur for this deliverable, including:
- information about its purpose
- guidance on how to create it
- a list of stakeholders interested in it
- Did the deliverable receive contribution from a wider community than the previous release, if appropriate?
- Is there any way to assess how it was received?
- Deliverable 2
- etc.
- etc.
Unfinished deliverables
- For each deliverable not finished:
- Why was it not finished?
- What was the impact?
- Is there a continuing need for this deliverable?
- If so, how can the team better prepare for and complete it for the next release?
New deliverables
- For each gap identified in the deliverables this release:
- Are there one or more specific deliverables that would close the gap?
- Is there any interest in producing them for the next release?
- Can they be produced with existing tools and services?
- If not, consider whether there are enough people skilled and interested enough to finish a project to create the tools/services needed. Not every idea can be made into a reality without hands to do the work.
- Would the new deliverable(s) replace/obsolete any existing deliverables?