Websites/Processes/Retrospectives/Release: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
Line 5: Line 5:
We’ll try to contain retrospectives to one hour. Here’s an outline to help facilitate the meeting. Open communication is the goal. Finger pointing isn’t. When scheduling a retrospective, copy the below agenda into the meeting invite or send via email.
We’ll try to contain retrospectives to one hour. Here’s an outline to help facilitate the meeting. Open communication is the goal. Finger pointing isn’t. When scheduling a retrospective, copy the below agenda into the meeting invite or send via email.


Title:
  <nowiki>
  <nowiki>
Title:
Retrospective Agenda for Mozilla Project XXX
Retrospective Agenda for Mozilla Project XXX
  </nowiki>
  </nowiki>

Revision as of 00:08, 15 April 2011

DRAFT: Release Retrospective Agenda Template

We should be doing post-mortems (ahem, I mean retrospectives) for all Mozilla projects. The purpose is to learn from our mistakes and improve our processes, as well as acknowledge and celebrate our successes.

We’ll try to contain retrospectives to one hour. Here’s an outline to help facilitate the meeting. Open communication is the goal. Finger pointing isn’t. When scheduling a retrospective, copy the below agenda into the meeting invite or send via email.

Title:

Retrospective Agenda for Mozilla Project XXX
 

Body:

To get a comprehensive review of all aspects of the project lifecycle, topics are broken down by phase and/or stakeholder. 
For each item below we will discuss “what went well” and “what can be improved” as well as the specific questions pertaining 
to each item.

Intro
* (Re)introduce the team
* Provide general overview and recap of the project.

Planning
* Was there clear requirements and a solid understanding of the app from the start?
* Were goals and success metrics clearly defined?

Design
* Did creative provide sufficient user stories?

Resources
* were roles/responsibilities clear?
* Were there sufficient resources to execute all phases smoothly within the project scope and schedule?    

Schedule
* Was the schedule realistic?
* Did anything cause the schedule to slip?

QA testing
* Did the development team adhere to QA’s checklist?

IT/Deployment
* Were there any issues getting the app onto stage?
* How did launch go?

Communication
* Were the channels of communication between all the stakeholders established from the start?
* Was there anything that blocked or hindered communication?

Summary

Action items