A proposal for managing upcoming projects for the MDN Engineering team.

Background

Work is requested from the MDN Engineering Team through a number of stakeholders, channels, and sources. When all of these sources are combined, the team has enough proposed work to last for years. Which work out of all these competing interests should come first, how do we give each stakeholder a fair amount of the team's time, and how can we emphasize doing the most important work in a way that is compatible with the self-directed development culture of Mozilla?

Current Situation

We select work based on the teams we are most in contact with. This puts us at risk of MDN becoming a Specialist Platform, a product geared to the needs of one group at the expense of the others.

Some of our competing channels, sources, and projects:

• Engineering team
• Writing team
• Evangelists team
• Marketing team
• Community
• Hacks Blog
• Demo Studio
• Dev Derby
• mdn-sphinx-theme
• Kuma technial debt: 1000+ open bugs (and growing)
• 170 MDN feature requests (and growing)

Goal

• Balance the requests of all of the stakeholders asking for features from the MDN development team so that each of the stakeholders get a fair amount of the MDN Engineering team's time.
• Make sure each stakeholder's most important issues are visible to everyone.
• Allow the MDN Engineering team choice in selecting the items they wish to work on.
• Make the upcoming MDN features and work visible to all stakeholders.
• Keep the engineering team responsive to incoming requests, so that they do not get locked into one one big project for an extended period of time.

Recommendation and Implementation

Each of the five stakeholder groups has 3 project slots for their use. The stakeholders fill up their project slots with 1-2 week iterations of projects, which the engineering team then selects work from.

1. Each of the 5 stakeholder groups selects their top 3 issues, in priority order, resulting in up to 15 project candidates.
2. The engineering team helps the stakeholders set SMART goals for their projects, discarding and selecting new project candidates if necessary.
3. The MDN Engineering team helps break the projects down into work iterations that are 1-2 weeks long, to help with work estimation and to provide more information to engineers when they are choosing projects from the menu. (e.g. T-shirt sizing)
4. Each of the five stakholders fill up their 3 menu slots with projects.
5. The engineering team members select one of the 15 projects to work on.
6. The team keeps finish and selecting new issues to clear our the first 15 projects.
7. After the 15 projects are complete, return to step 1 to refresh the menu

A Sample Menu

Engineering Team

Performance improvements (L) (2 week timebox)

Implement memcached (L)

Upgrade Django (L)

Writing Team

Redesign bugfixing (L) (2 week timebox)

Fix bug 123456 (S)

Rebrand Demo Studio / Dev Derby (M)

Evangelism Team

Localize the Hacks blog (bug 789012) (M)

Twitter Feed on Homepage (bug 345678) (M)

Community

Fix bar in the Localization dashboard (bug 901234) (XS)

Marketing Team

Update mdn-sphinx-theme (bug 567890) (M)