Firefox/Metro/WorkWeekII

From MozillaWiki
< Firefox‎ | Metro
Jump to: navigation, search

May 2013 Metro Work Week

When & Where

  • When: May 13 - 17, 2013
  • Where: Mozilla Vancouver Office (video tour)
    • 163 West Hastings Street, Vancouver, BC (Google Map)
    • The Mozilla office is on the second floor. Please buzz in at the front door: #209
    • Floor alarm code is 0512 And should be set by the last person out each evening.
  • Hotel: Delta Vancouver Suites 550 West Hastings St. Vancouver, BC V6B 1L6. Phone 604-689-8188
  • More information: Weather forecast
  • Shared Google Map with office, hotel, and restaurant locations

Food

  • Breakfast: 9:00 AM at Vancouver office
  • Lunch: Noon at Vancouver office
  • Team Dinner: Reservations have been made at the Irish Heather - 212 Carrall Street, Vancouver, BC V6B 2J2(604)688-9779

Objectives

  • Strategies to Improve:
    • Team Velocity
    • Quality and Defect Levels
  • Review and Revise V1 MVP Product Feature Set
    • Triage Backlog
    • Planning Backlog
    • Defect & Change Backlog
    • Story Backlog
  • Develop Aurora/Beta Release Criteria

Agenda

Sunday May 12

  • Travel Day

Monday May 13

  • Agenda Review and Work Week Objectives

  • State of Production
    • Development To Date - View Project Summary
    • Forecasts - Expected, Best Case and Worst Case: View Release Forecast
    • Backlogs - Story, Defect & Change, Planning, Triage:
      • Story Backlog - View
      • Defect & Change Backlog - View
        • 42 Defects/Changes in total to date.
        • 58 points estimated (128 available in contingency).
        • 22 require point estimations.
      • Planning Backlog - View
        • 11 items require editing.
      • Triage Backlog - View
        • 11 items require review.
    • Contingency:
      • Scope - 16 points held in reserve.
      • Defect - 128 points held in reserve.

  • Design Presentation
    • A presentation from Yuan about Firefox Design Values and 2013 FX UX themes.
    • [10:15am - 11am] A vidyo presentation from Bill Selman about Firefox User Types.

  • Backlog Review & Clearing
    • Triage Backlog - View
    • Planning Backlog - View
    • Defect & Change Backlog - View

Tuesday May 14

  • Scope Planning
    • Review of P4 and P5 stories to remove from V1 - Asa to lead discussion - View Story Backlog
    • Review of implemented but not ready for prime time features for remove from V1 - Asa to lead discussion.
    • UX Papercuts discussion - Asa to lead gathering of annoyances glitches that we don't have documented already.

  • Product Development Discussion
    • Stability issues
    • Performance Issues
    • User Data

  • Debugging Hacks & Demonstrations

Wednesday May 15

  • Production Performance
    • Velocity Performance
      • Benchmark average up to 10% increase in velocity per iteration.
      • As of Iteration #6, we have averaged a 23% increase per iteration.
      • To be updated at the end of each iteration.
      • Will assist the team to understand when velocity has stabilized and, in turn, when development has completed.
      • Will be used in conjunction with our velocity range calculation to gauge performance.
      • Patch Review Idea - Try for instant review if you understand the patch right away, otherwise try for same day review, otherwise comment with timeline. Reassign right away if you feel you aren't the best person for the review.
    • Quality Performance
      • Of all feature, defect and change stories submitted to QA for testing across all iterations:
        • 89% average pass rate.
        • 11% average fail rate.
        • 80% test coverage.
      • Baseline figures for future performance - to be updated at the end of each iteration.
      • Will assist the team to forecast and prioritize the number of defects up to the release date and determine which ones to transfer to V2.

  • Debugging Hacks & Demonstrations

  • Product Release Discussion
    • Aurora Uplift Criteria
    • Beta Uplift Criteria
    • Release Management - Bhavana Bajaj will join us via Video Conference.
      • What iteration are we looking at to sync with the release cycle? Do we have a goal here? Here's the link to Relase Management Calendar to help sync up the dates https://wiki.mozilla.org/RapidRelease/Calendar
        • Current forecast shows Nov 19 as 'expected' uplift to Aurora. Next mc merge after that is Dec. 9th, which puts us in the release channel on March 3rd, 2014.
          • Once the team velocity stabilizes we will be in a better position to pinpoint the merge date.
        • What features remain that we consider critical for an Aurora uplift? How can we move uplift to a more reasonable date (Aug. 5th merge / Oct. 28th release)?
          • The current expected and optimistic release forecasts do not support completion of development in August.
      • We should peek into metrics to get win8 ADI's on nightly(~20,000) ,aurora(<20,000) & beta(~95,000) to see if we are targeting the needed user population and have a strategy around uplift's.
      • Do our updates work fine? We should do a round of update testing on different win8 configurations . We never want to leave user's stranded an old build.
        • QA request, include round of update testing during the merge week when we uplift
      • L10n - How many locales are we planning on supporting ? Do we have a cut-off on this for launch?
      • Stability - Given the limited population on nightly it is hard to get attention or track any new crashers. But once we move up the trains this will change. So we will need more Engineering/QA attention to help resolve these (https://crash-stats.mozilla.com/products/MetroFirefox)
      • Get query of blockers ready to help track right bugs (metro-aurora-blockers, metro-beta-blockers).
      • Branding concerns ?

  • Debugging Hacks & Demonstrations

Thursday May 16

  • Team Discussion Points
    • Automation Planning
      • I understand that there is a multi-team group getting together to tackle this in the first week of June.
      • What can we do to help them hit that ground running?
      • Who's the point person from our group on this?
    • Maximizing Developer Hours
      • How long is too long to find new work?
      • How can we identify 'shovel-ready' bugs faster?
    • Who owns stories when the work bugs have many owners?
    • IRC Status Update - frequency has declined.
      • Need to be maintained on a daily basis.
      • More specific references to iteration work (Bug ID).
    • Final Iteration #7 Team Update

  • Debugging Hacks & Demonstrations

Friday May 17

  • Travel Day

Work Week Results

Triage Backlog

  • 6 items removed from V1 release.

Planning Backlog

  • 2 Feature Stories moved to Story Backlog ready for upcoming iterations.

Defect & Change Backlog

  • 4 Defect Stories removed from V1 release.
  • 31 of 38 Defect/Change Stories prioritized from P1 - P5.

Story Backlog

  • 9 P4 and P5 Feature Stories removed from V1 release.
  • 2 P4 and P5 Feature Stories promoted to P3 priority status.

Scope Contingency

  • Feature Story removals replenished our Scope Contingency from 16 to 77 points.

Strategies for Improving Team Velocity:

  1. If a bug is actionable, mark it [shovel-ready] in the whiteboard. Others may feel free to steal these, so if youre actively working on it, clear the flag.
    1. Also be sure to mark mentored bugs
  2. Only work on what you can reproduce, if someone else can reproduce it then transfer the work to them as quickly as possible.
  3. If you know how to fix a bug, dump the information in it to save other people time.
  4. If you're trying to fix a bug in an iteration and you're having trouble, transfer it back to the Story Backlog and let someone else pick it up on a later iteration. Don't be afraid to re-assign to someone else. Substitute with a bug you feel more confident in.
  5. Faster reviews, review it right away if you know what it is, take a day at most or warn that it'll take longer.
  6. Developers will use their discretion to determine if a defect found during iteration testing is a P4 or P5 priority status. Those that are will not be considered to block the feature story and it can be resolved.

Strategies for Improving Test Coverage:

  1. Each team member will participate in release testing on release planning day of the iteration (day 11) to assist the QA department in achieving a 100% test coverage.
  2. Metro will work with QA and Release Management to organize regular 'Metro Test Days' to gather community testers.
  3. Faster reviews, review it right away if you know what it is, take a day at most or warn that it'll take longer. This will help us identify and resolve defects quicker before the end of an iteration.

Aurora/Beta Release Criteria

  • Metro will prepare to land on Aurora in order to take advantage of the larger testing population.
  • Metro will not ride trains until development is complete.
  • Select features will be updated on Aurora to garner further user feedback.
  • Plans in progress to uplift to Aurora at the end of June.

Retrieved from "https://wiki.mozilla.org/index.php?title=Firefox/Metro/WorkWeekII&oldid=1198431"