Firefox OS/ProgramManagement/FunctionalTeamRollout

From MozillaWiki
Jump to: navigation, search

Archived from https://wiki.mozilla.org/FirefoxOS/ProgramManagement

Rollout Strategy

Team Kickoff Meetups

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

Day 1:

* 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:

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

Day 3:

  • 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

  • Roles and responsibilities
  • 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
  • Media
  • Performance
  • Browser
  • Comms (Dialer, SMS, Contacts)
  • Systems (Notification, Apps Install, Customizations)
  • RIL, BT, GPS
  • Settings Cost Control
  • GFX, Layout, Audio
  • Devices

Bugzilla Flags and Backlogs

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.

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 here

  • ACTION ITEM: Meetings between product, engineering, UX to:
      • Merge and consolidate multiple backlogs into one here 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

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 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