Websites/Processes/Retrospectives/Release: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
 
(7 intermediate revisions by 3 users not shown)
Line 1: Line 1:
==DRAFT: Release Retrospective Agenda Template==
There are 2 types of retrospectives that we will perform for each Mozilla website - a release retrospective and a [[Websites/Processes/Retrospectives/Website|website / campaign retrospective]].


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.
The release retrospective is to review schedule, scope, communication and more to improve on our processes. Campaign retrospectives will be conducted after a website or app is retired to review goals, metrics, ROI and the overall success of the product.


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.
The purpose is to learn from our mistakes as well as acknowledge and celebrate our successes.
 
= Release Retrospective Agenda Template =
 
We should 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:
Title:
  <nowiki>
  <nowiki>Release Retrospective Agenda for Mozilla Project {Website Name} </nowiki>
Retrospective Agenda for Mozilla Project XXX
</nowiki>


Body:
Body:
  <nowiki>
  <nowiki>
To get a comprehensive review of all aspects of the project lifecycle, topics are broken down by phase and/or stakeholder.  
You're invited to participate in a release retrospective for {Website Name}. Let's discuss
For each item below we will discuss “what went well” and “what can be improved” as well as the specific questions pertaining  
the nitty gritty in a constructive way (no finger pointing!) and help make future projects
to each item.
run more smoothly.
 
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
Intro:
* (Re)introduce the team
* (Re)introduce the team
* Provide general overview and recap of the project.
* Provide general overview and recap of the project.


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


Design
Design:
* Did creative provide sufficient user stories?
* Were there sufficient user stories?


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


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


QA testing
Development:
* Did the development team adhere to QA’s checklist?
* Was code freeze respected?
 
QA testing:
* Did development adhere to QA’s checklist?


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


Communication
Security
* Were there any issues in the security review process?
 
L10N
* Were there any issues in the localization process?
* Was string freeze respected?
 
Communication:
* Were the channels of communication between all the stakeholders established from the start?
* Were the channels of communication between all the stakeholders established from the start?
* Was there anything that blocked or hindered communication?
* Was there anything that blocked or hindered communication?


Summary
Summary:
 
Action items:


Action items
  </nowiki>
  </nowiki>

Latest revision as of 15:37, 24 April 2011

There are 2 types of retrospectives that we will perform for each Mozilla website - a release retrospective and a website / campaign retrospective.

The release retrospective is to review schedule, scope, communication and more to improve on our processes. Campaign retrospectives will be conducted after a website or app is retired to review goals, metrics, ROI and the overall success of the product.

The purpose is to learn from our mistakes as well as acknowledge and celebrate our successes.

Release Retrospective Agenda Template

We should 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:

Release Retrospective Agenda for Mozilla Project {Website Name} 

Body:

You're invited to participate in a release retrospective for {Website Name}. Let's discuss 
the nitty gritty in a constructive way (no finger pointing!) and help make future projects 
run more smoothly.

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:
* Were there clear requirements and a solid understanding of the website from the start?
* Were goals and success metrics clearly defined?

Design:
* Were there 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?

Development:
* Was code freeze respected?

QA testing:
* Did development adhere to QA’s checklist?

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

Security
* Were there any issues in the security review process?

L10N
* Were there any issues in the localization process?
* Was string freeze respected?

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: