Confirmed users
1,193
edits
MDN/Development/Process: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
No edit summary |
||
| Line 19: | Line 19: | ||
==== Organization ==== | ==== Organization ==== | ||
At times, features in the Product Backlog can become unnecessarily broad or vague. To avoid this, | At times, features in the Product Backlog can become unnecessarily broad or vague. To avoid this, we should break features down into smaller actions when necessary. For example, we might break up a feature about searching for demos by creating subtasks like"Create a mockup for demo searching" and "Research the tools that we could use to power demo searches". | ||
We should pay special attention to breaking things down when features become blocked. For example, if a feature has been planned in more than one Sprint without much visible progress (or even if a feature does not make much visible progress during the course of one Sprint), we could break that feature down into front-end and back-end components and complete one piece at a time. | |||
=== Sprint Backlogs === | === Sprint Backlogs === | ||
| Line 45: | Line 47: | ||
==== Planning ==== | ==== Planning ==== | ||
In the second part of the meeting, we build a new Sprint Backlog by looking at the Product Backlog and deciding which of the features we should complete in the upcoming Sprint. We plan for about two-thirds of our [https://docs.google.com/spreadsheet/ccc?key=0AtSmmChL-hpUdFNXeFVwbmZGMDFzbUhVQS1oQ0FnbFE&pli=1#gid=1 Sprint velocity] (the amount of work we normally complete in a Sprint), and leave the last third open for other features that developers choose based on their interests. | In the second part of the meeting, we build a new Sprint Backlog by looking at the Product Backlog and deciding which of the features we should complete in the upcoming Sprint. We try to keep a good balance of variety in the bugs we choose -- some front end, some back end, etc. -- so that everyone has something to work on that interests them. We plan for about two-thirds of our [https://docs.google.com/spreadsheet/ccc?key=0AtSmmChL-hpUdFNXeFVwbmZGMDFzbUhVQS1oQ0FnbFE&pli=1#gid=1 Sprint velocity] (the amount of work we normally complete in a Sprint), and leave the last third open for other features that developers choose based on their interests. | ||
After building the Sprint Backlog, we play [http://en.wikipedia.org/wiki/Planning_poker Planning Poker] to discuss the features in more detail and estimate how long it will take us to complete them. If Planning Poker reveals that we taken on more or less work than we usually complete, we add or remove features to the Sprint Backlog accordingly. | After building the Sprint Backlog, we play [http://en.wikipedia.org/wiki/Planning_poker Planning Poker] to discuss the features in more detail and estimate how long it will take us to complete them. If Planning Poker reveals that we taken on more or less work than we usually complete, we add or remove features to the Sprint Backlog accordingly. | ||
== Working == | == Working == | ||
=== Assignment === | |||
Between the start of the Sprint and the end of the Sprint, the development team works on the features that they added to the Sprint Backlog. When a developer knows that he will be working on a particular feature, he assigns that feature to himself. When he knows that he will no longer work on it, he updates the feature to be unassigned so that someone else can begin working on it. | Between the start of the Sprint and the end of the Sprint, the development team works on the features that they added to the Sprint Backlog. When a developer knows that he will be working on a particular feature, he assigns that feature to himself. When he knows that he will no longer work on it, he updates the feature to be unassigned so that someone else can begin working on it. | ||
=== Handling minor problems === | |||
Occasionally, the team runs into minor errors, usually in the form of error emails. These problems are usually not much of a problem on their own, but they can pile up over time. To handle this, the person affected should open a bug with the keyword [dev-papercut] in the status whiteboard. The team will watch a list of [https://bugzilla.mozilla.org/buglist.cgi?list_id=4440187;status_whiteboard_type=allwordssubstr;chfieldto=-4W;chfield=[Bug%20creation];query_format=advanced;status_whiteboard=[dev-papercut];bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;product=Mozilla%20Developer%20Network ignored papercuts] to make sure they don't pile up. | |||
== Updating the MDN == | == Updating the MDN == | ||
During the sprint, we occasionally add our new features to the MDN by pushing code to our production server. We push about once per week (usually on Tuesdays or Thursdays) and avoid pushing on Mondays and Fridays. | During the sprint, we occasionally add our new features to the MDN by pushing code to our production server. We push about once per week (usually on Tuesdays or Thursdays) and avoid pushing on Mondays and Fridays. | ||