Sprint planning

We currently work in two week sprints that run from Monday to the following Friday. Requests that come in mid-sprint will be placed in the backlog and triaged at the next sprint planning meeting. If something is urgent, please let us know and we can prioritize as needed.

For larger data, reporting, or analysis requests, the first action will be to plan a scoping exercise for the analyst or engineer in order to size the level of effort and determine where it sits in the overall priorities.

General outline of our planning process:

  • Thursday before a new sprint: synchronous sprint planning. Plan out the sprint 2-4 weeks out, and review the upcoming sprint
  • First Monday of the sprint: send out a message to #analytics with the wins from the last sprint and the plan for the current sprint (and a link to 2-4 weeks out if anyone wants to look)
  • First Friday of sprint: post updates to the issues in the sprint with a status and do an async review of where we’re at, if we need to push anything out or pull anything in
  • Repeat

Planning Principles:

  • OKR-driven
  • Mix of quick wins and long-term, proactive projects
  • Only choose projects where we have a clear picture of what the result looks like and the impact it will make; if these aren’t clear, we should block time to further scope them

Operating cadence

Calendar

Timing What
Quarterly OKR planning, including month 1/2/3 plan
Monthly Backlog grooming and retrospective
~10th of every month Rolling planning of next two sprints
~25th of every month Rolling planning of next two sprints
Monday standup Weekend, last week/this week summary, blockers/sprint risks
Wednesday standup Progress week-to-date, plan for rest of week, blockers/sprint risks
Friday Comment any any active issue in the current sprint with a status update

Issues

  • Minimum detail on a ticket (included in issue types in our tracker)
  • Every ticket should be in small enough chunk where it gets done within the sprint

A guide to Impact/Urgency - P0 - P4

Expectation Example
P0: Outage Drop everything else and work continuosly to resolve. An outage means that some piece of infrastructure that the community relies on is down.
  • Data in BigQuery is missing, a pipeline/transformation is erroring
  • A bug is found in an enterprise report/dashboard (watermarked)
  • A calculated field is incorrect or provides unexpected results in any monitored/business critical pipeline
P1: Critical Continuous status updates to stakeholders and managers, includes issues, but also any work with a short deadline or requested by and executive.
  • A bug is found in a non-enterprise report/dashboard
  • Errors in non-business critical pipelines or tables
  • Major degradation in performance
  • Any request with a deadline in the next two to three weeks (will include in current sprint or next sprint as needed)
P2: Default Most tickets will fall into this priority. These can be planned and executed by more than one person or in the next several sprints. There is no special urgency associated, but is a priority/OKR/stakeholder request that fits within our engagement model. Also includes, self directed work and analysis as deemed important by our team.
  • A new dashboard/report or an enhancement to an existing dashboard/report
  • A new data source pipeline with a concrete understanding of the final output of a report or the decision that we are looking to help provide insight on
  • A bug found in a table/pipeline that is not used any reporting
  • New technologies research
  • Optimizations
P3: Nice to have Non-critical improvements/efficiencies, any requests without clear outcomes/problems that we are trying to solve (placeholder tickets until more details become available)
  • New data source request without clear requirements on final dashboard or analysis
  • New dashboard or report with data that can be found elsewhere
  • Placeholder self-directed work for future scoping
P4 High level ideas for future work that may or may not rise in priority or small improvements with no criticality that should be fixed eventually
  • Additional documentation/comments in code
  • Ideas that come to you in the middle of the night

Story points

How much is known about a task Everything Almost everything Something Almost nothing Nothing Nothing
Dependencies None Almost none Some Few More than few Unknown
How much work effort <2 hours .5 days Up to 2 days Few days Around a week More than a week
Story points 1 2 3 5 8 13