User:CGauthier (WMF)/AndroidReleasePhases

Android team development cycle

The following is an outline of the team's standard process. It is important to ensure that everyone has a shared understanding of what each phase means. There are no pre-set dates or durations for phases, as the team will discuss timing as they work and agree together on when to move from one phase to the next.

1. Initialisation
   • Discuss concept with PM/engineers/UX research/analytics/RI and other teams to be informed
   • Prepare rough concepts/wireframes as needed to aid discussion
   • PM/analytics/UX research agree initial set of research questions (qual and quant)
2. Research
   • Present design proposal to engineers/design research/analytics for feedback
   • Engineers begin technical discussions
   • Write placeholder Epics
   • Create prototype for user testing (preferably using InVision or similar)
   • Initial evaluative user testing
3. Specification
   • Engineers agree on technical implementation details (and create mock APIs, etc)
   • Finalised designs and user flows completed and available in Zeplin (feedback to design as needed from engineers)
   • Analytics specifies tagging scheme based on research questions
   • Break out Epics into sub-tasks and link related designs to Phab tasks
   • Conceptual document available on-wiki, linked to related Phab tasks, etc
   • Most major unknowns should be identified, remaining work is understood
4. Development
   • Most functionality delivered to internal users for dogfooding/feedback
   • Scope trimmed to final size (remove tickets from board as necessary)
5. Feature Freeze
   • Only minor bugs and edge cases remain or added are to scope
   • Initial QA and design review completed on all epics
6. Code Freeze
   • Do pre-release smoke test and beta
   • Monitor beta release crash reports for at least three days before another beta release
   • Remove all “nice to haves” from the board
   • Only new tickets come from QA or tester feedback
   • Create a new branch from develop named as the version number for the release; any changes to the release are done as pull requests/patches targeted to this branch
   • Finalise marketing messages and materials, update app store assets
7. Release Call
   • Final check with engineers
   • Actual release happens
   • Release notes publicised
   • Documentation updated
8. Release
   • Duties should be rotated amongst engineers so that everyone understands the process.
   • Minor/bug-fix releases will be once per month, incorporating whatever bugs have been fixed and minor improvements have been made, that have passed QA and design review by the time we cut the beta. We will submit to beta on the Monday of the last week of the month, monitor for a few days, and submit to prod on the last Thursday if crashes/ratings/etc look fine.
   • Major feature releases will go out as and when the feature is completed as per checklist above, and needn't wait till the end of a month.

Rituals

These meetings ensure that the team maintains regular communication and has time for planning and board upkeep.

Name	Frequency	Duration	Description	Goals	Attendees
Grooming	every other week (alternating with Planning)	30 min	Team meets to clean up the release boards and backlog	Triage tasks and/or Groom tasks	Product Owner Engineers Designers Tech Program Mgr
Planning	every other week (alternating with Grooming)	60 min	Team meets to talk about a variety of different topics suggested by Product Owner, e.g., QA, work on current features, organisational updates, and to decide which tickets make it into current release board	Sync up on current work Document action items Decide on scope	Product Owner Engineers Designers QA (optional) Tech Program Mgr
Standup	on days when other meetings don't happen	15 min	Team meets to exchange quick status updates. Everyone but Facilitator answers three questions: What have you been up to since the last standup? What do you expect to be working on until the next one? Do you have any blockers? After giving their update, each person chooses who goes next by saying the other person's name.	Share what you've worked on Share what you'll be working on Share what's blocking you	Product Owner Engineers Designers Tech Program Mgr
Retrospective	every other week (alternating with Planning)	±45 min	Team meets to discuss topics proposed by team members, mostly process-related.	Discuss what's working well Discuss what could be improved Establish next steps to implement change	Product Owner Engineers Designers Tech Program Mgr