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

Status Artifacts
Epics are prioritized and tracked on the wiki under Analytics/Prioritization Planning.

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

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

Email
see.

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.

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.

Planning Poker
We have a tasking meeting every week. The product manager and scrum master are responsible for having stories ready to be estimated by the developer team.

We estimate stories in points and tasks in hours. We use a pseudo-Fibonacci sequence to estimate tasks (0,1,1,2,3,5,8,13...). The idea is that the Fibonacci number represents the size  of the story. Complexity is a factor when estimating the task but so is logistical and busywork as those add to size.

Examples: A simple story made up of a simple coding task is consider to be a 3. We always include writing tests and testing in staging in our estimation of the coding task. The simplest task you could think of would be a '1' but if it is worthy of a story it should be estimated.

The points help us calculate our velocity per sprint and see how are we doing as time and projects move along.

Every story is made of tasks and we estimate tasks in hours, we use hours cause we want to decouple the size of a story (measured in points) versus the duration (measured in hours). Obviously size and duration are related but their ratio is not always identical per story.