Getting in Touch
firstname.lastname@example.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/ .
Another way to make requests is to create a task in the "Analytics" project in Phabricator.
Classification of Work in Backlog
|Description||Level of detail|
|Tasks||the core work units belonging to a User Story
|Spikes||units of development reserved for research to support point estimation of a feature or tasking.||low|
Project: Editor Engagement Vital Signs Minimum Viable Product
- 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
- As an Analyst, I need visualization of session length KPI over period of 1 day, so that I can assess effectiveness of UI
- implement session start count
- implement session end threshold
- calculate session length
- 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
- Defects are logged in Phabricator under the "Analytics" project.
- 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
|Needs Triage||New backlog item that Product Owner needs to set priority|
|Unbreak Now!||Need to start next sprint|
|High||Need to start in the next sprint|
|Normal||Likely to be started within a month|
|Low||To do, but later|
|Needs Volunteer||new task not considered yet|
||IMPORTANT: The content of this page is outdated. If you have checked or updated this page and found the content to be suitable, please remove this notice.|
The backlog workboard in Phabricator indicates states of items by what swim lane or column the items is in.
New items are collected in the "Incoming" swim lane with a priority of "Needs Triage"
The next column to the right is "Epics." This column is a visual representation of the various Epics, and its placement is unrelated to any backlog state.
The next column to the right is "In Tech Review." Items here have been triaged by the Product Owner and are in review with the Dev team.
The final column on the right is "Ready for Dev." These items have been reviewed by team and are ready for discussion in tasking meeting with the goal of identifying all the underlying tasks and estimating a point value for the story.
From this column, stories will be pulled into sprints.
Once committed to for a given sprint, stories are pulled from this board an into the sprint board where each sprint is an individual project..
- We have many products and many stakeholders - most Agile perspectives assume a single product
- Team is completely distributed
- Team does not work on same project at the same time
- Infrastructure tasks are not well suited to Agile
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 week iterations or sprints. Note that a sprint ends on a Tuesday and a new sprint starts on a Thursday. The time in-between is for developers 10% time.
||Daily - 2pm UTC|
||Weekly - Thursday 2:30pm UTC|
||Fortnightly - Thursday at 5:00pm UTC|
||Fortnightly - Tuesday at 5:00pm UTC|
||Fortnightly - Tuesday at 5:30pm UTC|
The product owner and scrum master are responsible for having stories prioritized to be estimated by the team at the weekly tasking meeting.
We estimate stories in relative points or effort and tasks in hours. We use a pseudo-Fibonacci sequence to estimate (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 story 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 or the amount of work we can complete per sprint and shows 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.
|34||one person sprint if that person is not interrupted at ALL|
|21||one person sprint if that person is interrupted a moderate amount|
|3||simplest coding task|
|2||task involving some documentation|
|Google Docs Spreadsheet||