-
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 apply to issues in the Data Engineering github project.
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. Backlog issues shouldn't have an assigned Sprint.
Their Priority is relative to the other issues in the same sprint. If no sprint is assigned, it's inherited from their parent issue, or relative to the rest of the Backlog if there's no parent. An inherited Priority can be overridden to order sub-issues within a Project.
All data update issues are High priority.
Issues with the type Project capture a goal or collection of work that will take more than two sprints to complete.
They should have sub-issues to enumerate their full scope so that sub-issue progress is the measured goal progress.
Their Quarter indicates when they'll be worked on. A sprint may be assigned to indicate the target/actual completion date.
Their Priority is relative to all other open Projects.
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).
QA draft issues are sub-issues of their product build issue. A new draft supersedes the previous one and any that are still open when the build is distributed should be closed.
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".