Firefox OS/ProgramManagement: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
Line 1: Line 1:
==Rollout Strategy==
==Who==


===Team Kickoff Meetups===
* Candice Serran
* Michael Treese
* Kevin Hu
* Joe Cheng
* Ivan Tsay
* Wesley Huang
* Dietrich Ayala


Some teams have scheduled a three day meetup for functional team process kickoff. An example agenda:
==How==


Day 1:
TODO: fill in details below
* Team introductions
* Kickoff intro: Purpose and Goal of work week (Eng Mgr)
* High Level Roadmap for agile rollout and 1.2 (PO / EPM)
* FFOS Dev Process Training (EPM) - 1.5hr
* First pass review of user stories, acceptance criteria, UX wireframes, Scope etc (PO)


Day 2:
* Description of functional teams goes here
* Description Bugzilla process goes here
* Communication
** List the mailing lists
** List the weekly reports and sprint reports, etc


* Introduction to Estimation and Planning Poker (EPM)
==Functional Teams==
* Definition of Done (All Team)
* #1 planning poker session (target top half of backlog)


Day 3:
TODO: link to the teams page here


* Sprint Planning and commitment (all team)
* Incorporation of user stories into bugzilla (PO / EPM)
===Steps For Developing and Communicating Each Topic===
* Create a common consensus among leadership
* Document the decision with the goal of maximum penetration and education
* Insure that team receives the documentation and is encourage to digest it
* Training sessions
* Screencasts
* Documentation on the wiki
===What we need people to have a common understanding on===
* [https://etherpad.mozilla.org/AgileTeamRoles Roles and responsibilities]
* [https://etherpad.mozilla.org/AgileTeams What the teams are on FirefoxOS]
* How the scrum process works (flow diagram)
* How the flow works (flow diagram)
* Key deliverables at each handoff point (flow diagram)
* What a user story should contain
* Expanding user story bug with UX deliverables
* How to organize information in the backlog
* How to priorities and add buisness value points
* How to integrate user stories into bugzilla
* How to estimate add points to user stories
* How to run a scrum planning meeting
* How to manage dependencies
* Inter scrum team depedencies
* Platform team depedencies
* How to manage defects
* How to report on progress
* How to integrate release engineering
* How to integrate QA
===Audiences we have to ensure understand the expectations of the system===
* Senior Stackholders/Project Leadership
* Product Managers
* Engineering Project/Program Managers
* Development Managers
* UX
* Engineering Managers
* Engineering Developers
* QA
* Release Management
* Platform Egineering Managers
* Marketing and PR
* Launch Managers
===Suggested model from onboarding teams===
* We insert a experienced EPM with Scrum experience to run the iteration for the first iteration, they act as the Scrum Master
* Second round sees whomever has been assigned as the scrum master permanently to run the iteration with the EPM actively engaged
* Third around the EPM is monitoring the scrum master making sure that all is running well and putting out any remaining fires
* Fourth iteration, the EPM is no longer needed unless they are infact are he designated scrum master.
==FXOS Functional Teams==
* Productivity
* Productivity
* Media
* Media
Line 85: Line 34:
* Devices
* Devices


==Bugzilla Flags and Backlogs==
==Bugzilla Flags==


The team will be using the following tags for tracking user stories, associated tasks and priorities for all the functional teams.
The team will be using the following tags for tracking user stories, associated tasks and priorities for all the functional teams.
Line 103: Line 52:
** KOI:P2 are targeted features.
** KOI:P2 are targeted features.
** Sprint:X is the sprint in which this user story, task or bug will be completed.
** Sprint:X is the sprint in which this user story, task or bug will be completed.
==Process Definitions and Sprint Meetings==
===BACKLOG GROOMING===
Backlog grooming is an exercise between Product, Engineering, and UX to review current stories and feature sets to better flesh out requirements, dependencies, risks, assumptions and acceptance criteria. Acceptance criteria is a bulletized list that confirms when a user story is DONE.
'''Example Metro story with detailed requirements for reference is [https://bug831910.bugzilla.mozilla.org/attachment.cgi?id=720141 here]'''
* '''ACTION ITEM:''' Meetings between product, engineering, UX to:
** Merge and consolidate multiple backlogs into one here [https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0AtVT90hlMtdSdEd4TVVjWXNfU3ctMlVhWFRrWkpweVE#gid=12 FFOS Backlog]
** Define User Acceptance Criteria (UAC)
** List assumptions, dependencies, and risk
** High-level Tshirt size scoping
** Determine UX wireframe necessity for each story
*'''OUTPUT:''' Fleshed out user stories in above backlog template that has been socialized between all teams
===DEFINITION OF DONE===
Agreement between product, development, and QA on what quantifies a story as "done." (Are we measuring to code-complete or release-ready?) This list needs to be drafted, socialized, and published team-wide for broad communication and expectation. This will set the team up for story point estimation.
'''Example:'''
* User Acceptance Criteria (UAC) Complete
* QA test suite complete (Regression Success Rate)
* Product and UX Sign-off
===RELATIVE SIZING AND ESTIMATION===
Because there is high uncertainty on what we are building in software development, it is very difficult to size a feature or user story in time. There are agile techniques to help weight and size stories relative to other stories that a team has completed.  Since this is our first pass as a scrum team we will start with a base range and begin relative sizing as the team moves farther through their sprints.
*'''STORY POINTS:''' an arbitrary measurement that is unique to a scrum team. Scrum follows the fibonacci sequence because it allows variance for work effort. (1,2,3,5,8,13...)
*'''PLANNING POKER:''' an exercise whereby the engineering team (development and QA) complete rounds of conversation with the product owner and vote accordingly on point value for a specific story. If votes between team members differ significantly, a conversation is time-boxed to possibly uncover more information needed. The voting cycles 3 times and story point estimates start to converge to an agreed about value.
===BACKLOG PRIORITIZATION===
Given all the above requirements (Backlog grooming, defining done, and estimation) Product Owners are more equipped to weight priority among the user stories in the backlog.
===SPRINT PLANNING===
A planning session with all team members (development, qa, us, product, pgm) to review top priority stories in backlog, break down stories into work tasks, and COMMIT to completing them in the following two weeks.
===SPRINT DEMO===
All team participation lead by engineering to demonstrate done-work from previous sprint.
===SPRINT RETROSPECTIVE===
All team participation review of wins, challenges, and action items for improvement from previous sprint. This is a very important meeting for team to better understand if our process is working for our team.
==Agile Workflow==
[[File:Screen_Shot_2013-06-12_at_3.48.10_PM.png]]
==Agile Process Action Plan==
(for all functional scrum teams)
===Week 1:===
* Complete backlog grooming using this [https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0Ah4HhR7Qg1hxdHREb0xEZV9zTktoUWg5WEhRQ0kxbWc#gid=2 template] - (product, eng, ux team leads)
* Get some communication channels for discussion.
* Get alignment on roles and responsibilities
* Get alignment on rollout plan.
** EPMs will be responsible for driving the rollout.
* Work on aligment on the process.
===Week 2: (Ending June 14)===
* Draft document of scrum flow - handoffs and responsible individuals
* Present draft of process for small team
* Work alignment on process
** How to handle distributed teams
* Define, agree, socialize and publish definition of done - (all team)
* '''Key Milestone''': User story requirements, assumptions, and dependencies for 1.2 MVP
===Week 3: (Ending June 21)===
* Present draft of process. (agile team leads) - need to have a recorded presentation for Taipei team
* Finalize alignment on the process
* START: FFOS Development Process Training - (epm team)
* START: Agile Estimation training and Planning Poker (epm team)
* '''Key Milestone''': User Acceptance Criteria and High level scope (Tshirt sizing) for 1.2 MVP (gut check for 1.2 list)
===Week 4: (Ending June 28)===
* IN PROGRESS: FFOS Development Process Training
* IN PROGRESS: Estimation Training and Planning Poker
===Week 5: (Ending July 5)===
* IN PROGRESS: FFOS Development Process Training
* IN PROGRESS: Estimation Training and Planning Poker
===Week 6: (Ending July 12)===
* Key Milestone: All training complete
===Week 7: (Ending July 18)===
* Final prioritization and scoring for backlog - (product, eng, ux team leads)
* '''Key Milestone''': Partner communication and project scope - (pgm and epm teams)
===Week 7: (Ending July 25)===
* START: Sprint Planning
* '''Key Milestone:''' First sprint start
* '''Key Milestone:''' First sprint start

Revision as of 21:39, 28 October 2013

Who

  • Candice Serran
  • Michael Treese
  • Kevin Hu
  • Joe Cheng
  • Ivan Tsay
  • Wesley Huang
  • Dietrich Ayala

How

TODO: fill in details below

  • Description of functional teams goes here
  • Description Bugzilla process goes here
  • Communication
    • List the mailing lists
    • List the weekly reports and sprint reports, etc

Functional Teams

TODO: link to the teams page here

  • Productivity
  • Media
  • Performance
  • Browser
  • Comms (Dialer, SMS, Contacts)
  • Systems (Notification, Apps Install, Customizations)
  • RIL, BT, GPS
  • Settings Cost Control
  • GFX, Layout, Audio
  • Devices

Bugzilla Flags

The team will be using the following tags for tracking user stories, associated tasks and priorities for all the functional teams.

  • [UCID:xxx, FT:xxx, KOI:Px, Sprint:xxx]
    • Grammar
      • key and value, separated by a colon (no spaces)
      • key/value pairs separated by a space and comma
      • whole block contained within square brackets
      • case insensitive (eg, UCID and ucid are both valid)
    • Examples:
      • [ucid:System26, ft:systems-fe, koi:P2]
      • [UCID:Comms27, FT:comms, KOI:P1, Sprint:2]
    • All user stories have the [UCID:xxx] which maps back to user stories from Product.
    • If the bug is not a user story and simply a task, it will NOT have a [UCID:xxx] tag.
    • KOI:P1 is for feature that are must have for the release.
    • KOI:P2 are targeted features.
    • Sprint:X is the sprint in which this user story, task or bug will be completed.
  • Key Milestone: First sprint start
Retrieved from "https://wiki.mozilla.org/index.php?title=Firefox_OS/ProgramManagement&oldid=740044"