Firefox/Iterative Hello Development: Difference between revisions

Jump to navigation Jump to search

Firefox/Iterative Hello Development (view source)

Revision as of 18:15, 9 March 2015

394 bytes added ,  9 March 2015
re-ordered
(updated to new iteration and with team calendar)
(re-ordered)
Line 31: Line 31:
*** Fx36 released with marketing - so we expect to handle bugs from that higher push.
*** Fx36 released with marketing - so we expect to handle bugs from that higher push.
*** Mark working on [https://bugzilla.mozilla.org/show_bug.cgi?id=1106941 camera issue] fix.
*** Mark working on [https://bugzilla.mozilla.org/show_bug.cgi?id=1106941 camera issue] fix.
** Link-Clicker parity brainstorm next week.  Clarify goals from PM & UX perspective.  Technical problems that can be resolved with parity.  Putting into smaller pieces, impact/size of different work, and prioritizing work.


<p> </p>
<p> </p>
Line 45: Line 46:


<p> </p>
<p> </p>
===Past Iterations===
 
====Iteration - 39.1====
===Last Iteration - 39.1 (through March 9)===
* Tab Sharing collaboration with TB wrapped up - work on Replace Track fixes
* Break down Context work
<p> </p>
<p> </p>
<p> </p>
<p> </p>
Line 60: Line 63:


<p> </p>
<p> </p>
==Product Backlog==
<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>
The Product Backlog is continually maintained by the Hello Management team to ensure new priorities are available for each Sprint Planning meeting.
* Priorities follow the Firefox Desktop 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>
'''Product Backlog''' 
* [http://mzl.la/18g6hk2 Bugzilla Ranked "Firefox-backlog+" list]
**Add the "Rank" Column to your results and sort on Rank
***The option to "Change columns" is at bottom of search results
**Search is based on "Flags" - "contains the string" - firefox-backlog+
* [http://mzl.la/1zNex5S untriaged bugs]
* [http://mzl.la/1tTiXXC Tech-debt bugs] priority based on [https://etherpad.mozilla.org/brainstormtesthello etherpad discussion - though if you want one that's lower priority but impacting you - grab it]
* [https://trello.com/b/weRHRo0X/loop-sprints Trello Board] 
<p> </p>
==Backlog Triage==
<p> </p>
===Triage Guidelines===
<p> </p>
*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.
**MUST set Firefox-backlog to "+" (Shell will set all P1 and P2, as QE filters on this)
*"Iteration" should be set if you are taking a bug during a specific iteration.  EPM will clean up if bugs are closed before being taken into an iteration.
*"Points" should be set when known
===Triage Backlog===
* [http://mzl.la/1zNex5S View Bugzilla for untriaged]
* Adding Bugs to Triage
** Open a bug under Product:"Loop" || Component: "General" or "Client"
** The Blocking-Loop flag is defaulted to "---", which will go into our list of bugs to Triage next
** Hello team reviews for inclusion into a release backlog every 2 weeks
*If there is a bug that should be considered for taking ASAP - you can mark Blocking-Loop at "backlog ?"
**Before it can be "backlog ?" 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>
===Past Iterations===
====Iteration - 38.3 Performance====
====Iteration - 38.3 Performance====
* '''Firefox Release 38 Goal:'''
* '''Firefox Release 38 Goal:'''
Line 150: Line 217:
}
}
</bugzilla>
</bugzilla>
<p> </p>
==Product Backlog==
<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>
The Product Backlog is continually maintained by the Hello Management team to ensure new priorities are available for each Sprint Planning meeting.
* Priorities follow the Firefox Desktop 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>
'''Product Backlog''' 
* [http://mzl.la/18g6hk2 Bugzilla Ranked "Firefox-backlog+" list]
**Add the "Rank" Column to your results and sort on Rank
***The option to "Change columns" is at bottom of search results
**Search is based on "Flags" - "contains the string" - firefox-backlog+
* [http://mzl.la/1zNex5S untriaged bugs]
* [http://mzl.la/1tTiXXC Tech-debt bugs] priority based on [https://etherpad.mozilla.org/brainstormtesthello etherpad discussion - though if you want one that's lower priority but impacting you - grab it]
* [https://trello.com/b/weRHRo0X/loop-sprints Trello Board] 
<p> </p>
==Backlog Triage==
<p> </p>
===Triage Guidelines===
<p> </p>
*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.
**MUST set Firefox-backlog to "+" (Shell will set all P1 and P2, as QE filters on this)
*"Iteration" should be set if you are taking a bug during a specific iteration.  EPM will clean up if bugs are closed before being taken into an iteration.
*"Points" should be set when known
===Triage Backlog===
* [http://mzl.la/1zNex5S View Bugzilla for untriaged]
* Adding Bugs to Triage
** Open a bug under Product:"Loop" || Component: "General" or "Client"
** The Blocking-Loop flag is defaulted to "---", which will go into our list of bugs to Triage next
** Hello team reviews for inclusion into a release backlog every 2 weeks
*If there is a bug that should be considered for taking ASAP - you can mark Blocking-Loop at "backlog ?"
**Before it can be "backlog ?" 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>
<p> </p>


==Definition of Done==
==Definition of Done==
<p> </p>
<p> </p>
* The Definition of Done ensures a potentially shippable product increment is released at the conclusion of a release cycle.
* The [https://etherpad.mozilla.org/HsVyzOogAr Definition of Done] ensures a potentially shippable product increment is released at the conclusion of a release cycle.
<p> </p>
<p> </p>
* A potentially shippable product increment means compliance with the work's individual acceptance criteria and not the full story under development.
* A potentially shippable product increment means compliance with the work's individual acceptance criteria and not the full story under development.
Sescalante
Confirmed users
1,094

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/1060700"

Navigation menu