Analytics/Development Process

Purpose
This is a reference document to help you understand the processes followed by the Analytics Development Team.

Audience

 * Analytics Development Team
 * Stakeholders of Analytics who need details

Getting in Touch
[mailto:analytics@lists.wikimedia.org analytics@lists.wikimedia.org] is the best way to initiate communications with the team.

This is a public list and is archived at http://lists.wikimedia.org/pipermail/analytics/.

Work Breakdown Structure
For Example:

Epic: Editor Engagement Vital Signs Minimum Viable Product

Features:
 * CronUser runs report on entire project
 * User runs report for Newly Registered User
 * User runs report for New Editor
 * Analyst selects metrics to graph
 * Analyst selects projects to graph
 * etc.

Stakeholder Communications
Epics are prioritized and tracked on a wiki page.

Features are tracked in Phabricator. Each feature has points and tasks associated to it.

Showcases are run every two weeks (at the end of a sprint) to demonstrate progress. See also.

Production Issues

 * Production issues are always top priority
 * If you’re not sure if an issue is a production issue ask peers/managers/directors/VPs
 * We track these against a special Epic called Production Issues - Q(1-4)
 * We track them in a Epic so we can identify patterns, development metrics, etc.
 * Fix the problem first, create the card later

Bug Triage

 * Defects are logged in Bugzilla under the 'Analytics' product - https://bugzilla.wikimedia.org/buglist.cgi?list_id=314657&product=Analytics&query_format=advanced.
 * Non urgent bugs will be dealt with as part of the regular backlog and backlog grooming process
 * Urgent bugs will be tagged as production issues and dealt with immediately

Quirks

 * We have many products and many stakeholders - most Agile perspectives assume a single product
 * Our releases correspond to quarters (They probably shouldn’t be called releases)
 * Team is completely distributed
 * Team does not work on same project at the same time
 * Managing infrastructure tasks in an agile way is challenging

Ceremonies
Ceremonies are meetings that adhere to Agile/Scrum methodology and help coordinate the team, deepen understanding of the requirements and prioritize features. They also set the team's cadence to two weeks. Note that a sprint ends on a Tuesday and a new sprint starts on a Thursday. The time in-between is for developers to perform undirected tasks, research or maintenance.

Sprint Planning
TBC