MDN/Archives/John's gone. What now?

My internship ended in August 2011, but there is always more to do. In this document, I share information that should allow anyone to pick up where I left off. Please be aware that this document is not meant to be an overview of what I accomplished during my internship. For that, please download my internship presentation. --John Karahalis

What I Did

Here, I outline day-to-day responsibilities by timeframe.

Just before each planning meeting

• Open the sprint backlog of the previous sprint (assuming it has already been pushed) and manually add the points of all completed stories. This is the velocity of the previous sprint.
• Estimate the velocity of the next sprint
  • Add the velocity of the previous sprint to the MDN Development Team Velocity document
  • In the same document, enter the length of the upcoming sprint
  • The spreadsheet will automatically calculate predictions for the next sprint. Note these predictions.

During each planning meeting

• Take meeting notes. (I usually used EtherPad, but any format is fine.)
• Hold a short retrospective discussion and record all thoughts in the Retrospective Document
• Work with team to decide on a sprint goal
• Build a sprint backlog
  • Work with team to select high-priotity items from the MDN product backlog
  • Ensure that the team decides on a point estimate for each selected item. Planning poker can be used here.
  • Ensure the total number of points for the selected items is slightly above the velocity predictions, maybe 10%-20% higher. It is usually better to overcommit and push work out than to undercommit and run out of work halfway through a sprint.
  • Updated each selected item with the appropriate Bugzilla milestone
• Decide on dates for code freeze, push, and other important events

Right after each planning meeting

• Update the Status Meetings Wiki page with a link to the meeting notes
• Update the MDN Milestones page with a section for the new sprint
  • Follow the format used for other sprints
  • Provide the sprint goal and relevant dates that were decided in the planning meeting
  • Provide a sprint backlog
    • Open the sprint backlog of the previous sprint, click "Edit search", and change the milestone to the milestone of this new sprint. This helps ensure that all query preferences (columns, sorting, etc.) do not change from sprint to sprint.
    • Follow a similar process when breaking the sprint backlog down by team member. Open the buglist of a particular team member from the last sprint and change the milestone. Do this for every member of the team.

Every day during the sprint

• Read through all Bugzilla updates to ensure the team is progressing. Answer questions, break up bugs, and do other organizational work when necessary.
• Start a Daily Scrum in IRC every day at 1pm Pacific
  • Ping all team members
  • Ask the three questions: 1. What have you been working on since the last time we met? 2. What will you work on until the next time we meet? 3. Are you blocked by anything?
  • Watch carefully for responses to question 3. Take all answers to this question very seriously. Always take some kind of action to resolve the issue mentioned.
  • After the three questions have been answered, ask if the team is progressing well toward the upcoming code freeze ("Do we think we will finish in time for the 1.0 code freeze?").
  • Note any potential problem areas that are mentioned. Be sure to follow-up on these issues in future Standup meetings.

After each sprint

• Read through the Retrospective Document and ensure that all or most of the issues raised in the last retrospective discussion have been resolved during the sprint. If they have not, plan to resolve them in the next sprint.
• Begin the feedback process described in the Kuma Testing and Feedback email
  • Do all work described in the section "What I will do"
  • Ensure all recipients are able to complete the work described in the section "What you can do"

What Remains

Goals

Ongoing goals that I worked towards during my internship.

• Improve development processes
• Help with Kuma user research, especially for features related to profiles and dashboards
• Help recruit creative web developers for the Dev Derby
• Help with work related to SEO and SEM

Tasks

Additional tasks that were on my radar when my internship ended. Each task is listed with a priority, which are based on my discussions with Jay.

• [High] Continue opening bugs based on user interview with Sheppy
  • This has taken a long time, but it is very valuable work
  • Jay has a recording of the user interview and a document outlining what features he talked about with timestamps
• [High] Continue opening bugs based on user interview with Atul
  • Jay has the interview notes
  • Start with his thoughts on cross-compatibility. Bugs were created for all other topics already.
• [High] Start opening bugs based on user interview with Dan Mills
  • Jay has a recording of the user interview
• [High] Open bugs based on feedback sent by Lloyd
  • Lloyd send some feedback by email. Jay has a copy of this email.
• [High] Email Sheppy, Dan, and Lloyd. Link them to the bugs I created in response to their thoughts and ask for feedback, clarifications, and additional thoughts
• [High] Estimate team velocity and send Janet and Sheppy a long-term roadmap
• [High] Get the community involved with Kuma testing and feedback
  • Let them know what a release includes and what we are planning for the next few releases (a simple roadmap) so that they don't waste time requesting features that are already planned
  • Set up the proper channels for feedback
  • We might just need to involve the community with our Kuma Testing and Feedback process, perhaps with some small tweaks
• [High] Create personas based on existing MDN users
  • Identify 3-4 representative groups and create a persona for each of those groups
  • Be sure each persona has a name
  • For the first few sprints, the team will focus on developing for the most important 2-3 personas
  • Some possible personas:
    • Student learning about technology
    • Localizers
• [High] Share the personas with the MDN development and Developer Engagement teams to get feedback
  • Make sure they accurately represent the types of people using the site
  • Make sure that each persona is thorough, that it encapsulates everything its respective group cares about
• [High] Identify one task for each group of users
• [Med] Write announcements for the about:mozilla newsletter about every two weeks
• [Med] Start thinking about web analytics
  • Analytics will be built into Kuma
  • Should some analytics be public and others private? Should everything be public?
  • What data do we want to collect?
  • What kinds of data do PiWiK and Open Web Analytics collect?
• [Med] Hold user interviews regarding the planned Scrum Dashboard
• [Med] Continue holding Kuma user interviews
  • Don't interview too many people from the same persona
• [Med] Continue triaging the MDN product backlog. Close invalid bugs, merge duplicates, respond to some, etc.
• [Low] Clean up the "Possible Dev Derby / Demo Studio Contributors" spreadsheet
  • Draw some kind of distinction between individual people and organizations to make automated email personalization easier
  • Make it easier to note that one author has multiple interesting demos out on the web. Maybe decouple authors and demos, putting authors in one sheet and referencing them in a separate "demos" sheet.
  • If a person or organization is listed in the "Blacklist" sheet, all related rows in other sheets (contact information, demos by that author, etc.) should have a black or dark gray background
  • It should be possible to update any sheet and have those updates reflected in other sheets. At the moment, only the first two sheets can be edited.
  • etc.
• [Low] Share the "Possible Dev Derby / Demo Studio Contributors" spreadsheet with the Developer Engagement team to get their additions
• [Low] If we continue the email campaign, clean up the email customization script
  • Automatically create Thunderbird drafts. Currently, the script prints customized email bodies to stdout.
  • If contacting a person, the first line should be "Hi [Firstname],". If contacting an organization, the first line should be simply "[Organization],"
  • Decent README documentation
• [Low] Search for people doing creative work with new technology that will soon land in Firefox
• [Low] Start thinking about UserTesting.com and the kinds of usage we would like to test
• [Low] Start running UserTesting.com tests with 5-10 users
  • Focus especially on features related to review and features related to finding documents to work on
  • Tip from Diane: "[When you get a notification about a new video], ask UserTesting.com for the raw file, that way you will have it locally and it's not just stored under your account with them."
  • Offer from Diane: "If you send me a draft of your scenario and your tasks for UserTesting.com, I can review them."

Important Resources

• Meeting notes and documents I created this summer
• Chat logs and audio recordings of user interviews. Jay has copies of these.
• I have some other assets that might be useful to the team, including a script to scrape Chrome Experiments, the template I used for emailing potential Dev Derby contributors, etc. In the interest of time I will not post all of these now, but please let me know if you would ever like copies.

Anything else?

Did I miss something? Please feel free to email me or ping me on IRC with any additional questions.