-
Notifications
You must be signed in to change notification settings - Fork 3
Planning and Tracking Work
To plan and track our work we use:
- Data Engineering github project
- Data Updates github project
- Data Engineering channel in Microsoft Teams
To coordinate cross-team work we use our github project, the edm-overview repo, and any other repos other teams may be working in.
We use the DE Quarter Retro and Planning doc to document goals and initiatives for each quarter of the year.
We use the DE Data Catalog spreadsheet to document the release schedule for our data products.
We use these to align plans across the division: GDE Roadmap, ITD Projects Portfolio, ITD Project Intake.
Our periodic meetings are:
- standup on Monday/Wednesday/Friday
- biweekly sprint planning and retro
- the first and last days a sprint
- meeting notes
- monthly roadmapping
- the first Wednesday of a month
- meeting notes
- quarterly retro & planning
- during the last sprint of a quarter
- meeting notes
These conventions primarily apply to issues in the Data Engineering project.
Issues with the type Project capture a set of work that will take more than two sprints to complete. They should have sub-issues breaking down the work involved.
Their Quarter indicates when they'll be worked on. A sprint may be assigned to indicate when it was completed.
Their Priority is relative to all other open Projects.
Non-project issues capture work that will take a sprint or two. They may have sub-issues to help break down the work involved.
Their Sprint indicates when they'll be worked on.
Their Priority is relative to the other issues in the same sprint.
Closing a parent issue requires resolving its open sub-issues first.
An issue is triaged if it has a type, status, priority, and any relevant labels.
Untriaged issues have a New status. An issue still in New after 30 days should either be triaged or closed.
Issues in the current sprint are planned to be completed in this sprint.
There shouldn't be any New or Backlog issues in the current sprint.
Issues opened by scheduled actions are typed and labeled like any other issue (e.g. Bug for a Scheduled Action Failure, Task for a QA draft).
Repeat failures of the same action are deduplicated: keep the latest open issue, note the first-seen date, and close the rest as duplicates.
An issue with no activity for 12 months that isn't a Project or a sub-issue of one should be closed as "not planned".
(draft idea, not using yet)
Some Project issues declare a SMART goal rather than hold a container of work. A goal Project:
- states its outcome and its deadline in the title
- enumerates its full scope as sub-issues, so that sub-issue progress is the measured goal progress
- names what's in scope rather than counting it ("convert the PLUTO, DevDB, and FacDB builds to dbt", not "convert 5 builds to dbt")
Project issues whose scope can't be enumerated up front stay containers of work.