-
Notifications
You must be signed in to change notification settings - Fork 30
Development Workflow
- Local team sync
- Local team PO meeting
- PO meeting
- Sprint planning meeting
- Update in toolchain-standup channel
- Sprint review meeting with retrospective
- POs add a milestone tag for the next sprint
Workshops: we should aim to have 1-2 of these per sprint. These may be best to have in local teams, or across Atlantic. Whichever mode, notes should be taken, added to the collection, and broadcast to the whole team.
Review tasks from the sprint.
Prepare mini-presentations for the upcoming sprint review.
Go through open issues and ensure there is no overlap in what was done. If there was, close those issues.
Mini review of current sprint.
Go through tagged issues and PRs for the next and make sure PO agrees.
Draft 2-3 sentences to describe the priorities for the sprint (could be just the epics planned).
Discuss administrative issues.
Discuss direction of project and upcoming work.
Present tagged issues and PRs for the next sprint and groom these.
Whole team present if possible.
When a task is accepted for the sprint, ensure the sprint milestone tag is placed on the task, and remove the Sprint Planning label.
Discuss the distribution of work for the marked items —formulate loose plan.
Discuss blockers. If there is agreement that a issue or PR is still vaguely defined, then it is either broken down into sub-tasks (if known), or switched to a “design issue”
Every item tagged with the sprint milestone should now have a clear outline, defined definition of done (DOD), and the team members assigned should have an idea how to achieve it
“Design issues” should have a complementary document ready by the end of the sprint detailing how the team should go about handling it
Notice here that velocity is implicitly calculated because each task that is assigned is properly defined. At the current time we are not using story points.
At the end of each workday (or so) describe any blockers or relay information to the other teams about join tasks (e.g. refactoring) that may affect them.
Any new PRs that were worked on should be marked with the sprint milestone
Presentations on epics and large tasks.
Built-in retrospective of what went well and what could be improved
Review upcoming milestones and events that will impact the next few sprint cycles
We use Zenhub to organize tasks. There are three columns: Backlog, In Progress, and Done. During the sprint planning process, issues are tagged with "Sprint Planning" and then the specific milestone tag. Once the issue is getting addressed during the sprint, it's moved into the "In Progress" column, and finally closed.