Mozilla Metrics: Difference between revisions

Jump to navigation Jump to search

Mozilla Metrics (view source)

Revision as of 20:28, 24 April 2015

11,525 bytes removed ,  24 April 2015
reverted edits that were in the wrong wiki space
(adding nee template, pushed down old doc)
(reverted edits that were in the wrong wiki space)
 
Line 1: Line 1:
=Project Name=
problem statement or why we do this project for someone brand new.
==Project Introduction==
* '''Team Mailing list:''' ex: [[Firefox/dev-media]] or the general team mailing list (doesn't need to be project specific)
* '''Team IRC Channel:''' ex: [irc://irc.mozilla.org/loop #loop] or the general team channel (doesn't need to be project specific)
*[https://wiki.mozilla.org/Platform/Roadmap#WebRTC_.2F_WebAudio Summary of our plans for this year] (links back to main page for the area - ex: platform or desktop have roll-up pages with very high level goals)
*[https://mozilla.aha.io/published/fc5d6de0471e12abc297b3de748d972e?page=1 More detailed Roadmap], noting that the further out the more lose the targets are
* '''Dependencies:''' feature, partner, resource, etc. - put links to other project pages.
==Links to Current info==
The [https://wiki.mozilla.org/Program_Management/ProjectPlanTemplate/Firefoxdesktop/Links Links wiki page] is the central location for current focus, Roadmap, Metrics, UX, Marketing, tech-architecture, and more.
==Roles and Responsibilities==
The [https://wiki.mozilla.org/Program_Management/ProjectPlanTemplate/Firefoxdesktop/Contacts Contacts Page] has the Roles and Responsibilities for this team, partner teams, and external partners involved in this project.
==Meetings & Communications==
<p> </p>
{| class="wikitable"
|-
! Meeting !! Day of week !! Pacific Time !! Eastern Time !! Central European Time !! Vidyo Room !! Notes
|-
| "Stand-up" Meetings || Monday, Tuesday, Wednesday, Thursday || 8:00AM - 8:30AM || 11:00AM - 11:30PM || 5:00PM - 5:30PM || webRTC-Apps || [https://etherpad.mozilla.org/haeLwWEkZV etherpad]
|-
| "Pull Meetings" || bi-weekly at the start of the iteration on ___ || 8:00AM - 8:30AM || 11:00AM - 11:30PM || 5:00PM - 5:30PM || webRTC-Apps || [https://etherpad.mozilla.org/haeLwWEkZV etherpad]
|-
| "Retrospective" || Friday || 8:00AM - 9:00AM || 11:00AM - 12:00PM || 5:00PM - 6:00PM || webRTC-Apps || [https://etherpad.mozilla.org/loop-retrospectives etherpad]
|}
*Links to mailing list or all communication channels
<p> </p>
=Development=
<p> </p>
==Schedule==
'''Release timing'''
*[https://wiki.mozilla.org/Release_Management/TeamWiki Firefox main release schedule] is the master location for the dates when each Firefox version goes to Aurora, Beta, & Release.
'''Sprints''' (if team is using 2 week sprints)
*[https://wiki.mozilla.org/Firefox/IterativeDevelopment#Upcoming_Iterations schedule for 2 week increments (3 Sprints per Fx Release)]
**There is a field in Bugzilla there is a field for "Iteration" that has the iteration number and the last day in that sprint:
***<FxRelease#>.1 - <last day before uplift>
***<FxRelease#>.2 - <last day before uplift>
***<Fxrelease#>.3 - <last day before uplift>
==Upcoming Priorities and Project Health==
As we plan what's coming next, these are areas being discussed.  This is not a commitment to the next projects - just our scratch area, but it is in order of relative priority.  (after the work we've pulled for the sprints).
*finishing Theme 1 (large change)
*Theme 2: any time constraints/dependencies
*Theme 3: quick why
Things we want to do - but parking lot until higher priorities are done:
*Process Improvement: Theme
*Other platform Investigation
*Tech-debt: any time constraints/dependencies
*Theme 4
*Quality: description of areas
*Theme 5
'''Risks'''
*Risk 1 : ex: Roadmap goals for the release in November are too high for ____(dev, UX, PM?) resources by x amount (bugs? points? UX resources).  likely will not make any features beyond x, y, z.
*Risk 2 : ex: Dependency on a service that is not established/planned for from another team.  Need help prioritizing if we should delay the feature in this project or raise the priority in the other team based on their existing backlog
==Current Status==
[https://wiki.mozilla.org/Mobile/Firefox_for_iOS/Status_Report/21-Apr-2015 example from Jenn's]
==Project Health==
[[File:IOS,Desktop Yellow Risk.png|frameless]]<br>
*(get central location for graphics from Erin)
Include clear, executive level summary that will be included at the [[https://mana.mozilla.org/wiki/display/PM/Firefox+Program mana page overall view level]:
*for company goal x, we are in _____ state because ______.  Please consider ______(propose fix or adjustment of goal).
*for release goal for ______ ,  we are in _____ state because ______.  Please consider ______(propose fix or adjustment of goal).
==Current (queries)==
*Many options for how teams want to present this information. 
*[https://wiki.mozilla.org/Program_Management/ProjectPlanTemplate/Queries Sample queries to visualize the bugs] in bugzilla
*Some examples of teams using [https://wiki.mozilla.org/Firefox/Iterative_Hello_Development#Current Iteration], by [https://wiki.mozilla.org/Media/Webrtc#Releases Release], by tracking bug
==Past==
*Pipeline of work that has been completed and moving through Aurora and Beta to release.
*Ideally these aren't just queries, but human readable so folks know what is coming in x release.
=Product Backlog=
==Key Bugzilla Queries==
*put key queries here so folks can find simply
<p> </p>
All work related to the ongoing development and maintenance of the Firefox Desktop Product are collected and prioritized in the Product Backlog.  The goals of the Product Backlog are to:
* Enable work to be prioritized so that the team is always working on the most important features.
* Support continual planning as the product emerges so the plan matches reality.
* Improve forecasts so that the stakeholders make the best decisions about the direction of the product.<p> </p>
==Bugzilla Agile fields==
Several Fields have been added this year into bugzilla for Agile tracking that you may want to leverage:
*'''Iteration''': right now this has the 3 previous and future 2 week sprints for Firefox release schedule - shows iteration (40.1) and uplift date.
*'''Points''': Fibonacci series 1,2,3,5,8,13]
*'''Rank''': see Rank use description under [https://wiki.mozilla.org/Program_Management/ProjectPlanTemplate/Firefoxdesktop#Triage_Guidelines Triage Guidelines]
**Rank will not show under your Product::Component unless you request it by filing a bug with "bugzilla.mozilla.org :: Administration".  You need to give a list of acceptable editors (usually the folks that can triage).
<p> </p>
<p> </p>
'''Product Backlog''' 
*There needs to be a way to mark the bugs you have triaged versus not.  Firefox uses the flag for "firefox-backlog". 
*If you are not strictly desktop, there's also an option to add you team to the blocking-flag "backlog". 
**ex: the webRTC team uses webRTC+ for bugs they are accepting and "parking lot" for ones they are not.  The queries are based on product/component - so multiple teams can use "parkinglot" and just request a new tag <team name>+ tag by filing a bug under "bugzilla.mozilla.org :: Administration"
*ex: [http://mzl.la/18g6hk2 Bugzilla Ranked "Firefox-backlog+" list]
**Add the "Rank" Column to your results and sort on Rank to view order of work.
***The option to "Change columns" is at bottom of search results
**Search is based on "Flags" - "contains the string" - firefox-backlog+
*[http://mzl.la/18Xoxhm Un-triaged bugs]
**Search is based on not having the Firefox-backlog+ or Firefox-backlog-
<p> </p>
==Triage Guidelines==
The Product Backlog is continually maintained by the Hello Management team to ensure new priorities are available for each Sprint Planning meeting.
* Priorities follow this Standard:
** Priority 1 - Blocker, must-fix before shipping.
** Priority 2 - Major impact,  considering severity × probability. Not a blocker for shipping.
** Priority 3 - Average Bug.  definitely a problem, but doesn't stop someone from using the product.
** Priority 4 - Minor or polish bugs that are real issues (especially in aggregate) and annoying.
** Priority 5 - Low-impact. something we'd fix, but mostly only bothers the discerning user. Little impact on usability.
*RANK: As priority buckets start to have a large amount of bugs in them, the Rank field can be used to call attention to higher or lower rank and provide a way to sort easily in bugzilla.  To have some rhyme/reason to the order - Rank should relate to Priority.  The "Ranking" number does not need to be unique. Unless there is a reason to for a bug to be considered before (or after) others in the Priority bucket - default to mid-range value.
** P1  Rank options=1-19, default 15
** P2  Rank options=20-29, default 25
** P3  Rank options=30-39, default 35
** P4  Rank options=40-49, default 45
** P5  Rank options=50-59, default 55
** any that we don't think we can get to in the next 6 months should go in "backlog-" area
<p> </p>
*The Firefox-backlog flag is used to track bugs that are approved for the Backlog "+"
*QE-Verify is a flag that developers should be setting on bugs they are working on. This is used for QE to filter which bugs they check
**"+" means that QE should look at the bug and it can be verified with human eyes
**"-" means QE should not look at
***Typically goes with in-testsuite set to "+", to show testing via another method.
*"Points" should be set when known (if nothing set - assumed a "1" or very small).  Most relevant if taking a bigger bug so we know when bugs are large bits of work.
*"Iteration" should be updated when a bug is being worked on during a particular Sprint.
==Filing a bug==
** Open a bug under Product:"Loop" || Component: "General" or "Client"
** Hello team reviews for inclusion into a release backlog every 2 weeks, and will mark "firefox-blocking" accordingly
*If there is a bug that should be considered for taking ASAP - you can mark "firefox-backlog"+
**Before it can be given a Rank it should:
*** be in an actionable state
*** for defects, the problem is ready for Engineering or UX: diagnosis, measurement, design, or fixing
*** for feature requests or enhancements, it means that there's a clear problem statement or suggestion
*** has a difficulty/user-impact ratio low enough that we can reasonably expect to spend time fixing the bug within the next 6 months
<p> </p>
=Templates=
Go to [https://wiki.mozilla.org/Program_Management/ProjectPlanTemplate/Firefoxdesktop/Templates Templates page] for sample etherpads, invite details, etc. for the following types of meetings.
* stand-ups (daily, weekly, or other)
* retrospective invites with questions/structure of the meeting in etherpad
* cross-team/company meeting invites/etherpads to keep efficient and only when needed
* postmortems
=Archive =
as iteration information or links get old or if this is replacing an older page and we don't want to lose path to the information...link to an archive page from here.
==Reference materials==
===Sample bugzilla Queries===
Please [https://wiki.mozilla.org/Program_Management/ProjectPlanTemplate/Queries add your queries and descriptions] of what they are doing here to help other create without having to learn bugzilla!
*Queries to pull info for an iteration
===Tools===
*Aha
*Trello
https://waffle.io/mozilla/payments
===Reading===
*Agile Retrospectives: Making Good Teams Great by Esther Derby
*https://pragprog.com/book/dlret/agile-retrospectives
*http://www.jamesshore.com/Agile-Book/retrospectives.html
*https://www.crisp.se/file-uploads/Lean-from-the-trenches.pdf
*http://shop.oreilly.com/product/0636920033851.do user story mapping as a too
*Buidling great teams https://hbr.org/2012/04/the-new-science-of-building-great-teams
Older:
Metrics Program : Executive Dashboard Project
Metrics Program : Executive Dashboard Project
* [https://docs.google.com/a/mozilla.com/presentation/d/1tKBykmAMss93NuMcEssuQOnEeJMYsEP4U-wR7cYe2Xo/present#slide=id.p Kick-off January 2015]
* [https://docs.google.com/a/mozilla.com/presentation/d/1tKBykmAMss93NuMcEssuQOnEeJMYsEP4U-wR7cYe2Xo/present#slide=id.p Kick-off January 2015]
Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/1070262"

Navigation menu