The goal of the cycles is to keep track of a pre-defined set of work in a short, time-boxed period and, when the goal is met, to deliver a release as an outcome.
Developers
Responsibilities
- Daily Check-ins:
- Cycle Board Usage:
- Retrospective:
Cycle Lead
A cycle lead’s primary responsibility is to keep the development team organized and progressing on the cycle goals, in order of priority. In other words, the cycle lead is there to help keep the team on track.
Responsibilities
- Daily Check-ins:
- Facilitate daily standup meetings. The cycle board should be visible and be effectively used during these meetings to easily keep track of who’s doing what and if anyone is blocked and in need of help.
- Remind test & review issues: Tests are a crucial part of our cycles and reviews
- Remind the team of test & review issues. It’s usually easy to forget them or postpone doing them.
- Remind the team of the next release when the cycle end date is near. So that the team can have enough time to prepare the images and release notes.
- Ensure
#checkin channel usage. Encourage usage of the Slack #checkin channel. Don’t hesitate to remind developers if their check-in notes are not clear, precise, or missing altogether.
- Cycle Board Administration:
- Work as the admin of the cycle board. Daily review of the board may be helpful to keep track of these things. Additionally,
#updates-linearapp is very helpful to get notified of any updates.
- Ensure that issues are up-to-date Make sure the team updates their issues as “in progress” when they’re working on them and, if necessary, create a review sub-issue once they’re done with the issue.
- Make sure any ongoing work has an issue in the cycle. It’s sometimes easy to wander off the existing issues and work on something outside of the cycle that intrigues us. So don’t hesitate to remind the developer to keep working on the existing issues.
- Make sure there isn’t any issue with a missing label or estimate. Don’t hesitate to remind the assignee to make an estimation. Every issue should have an estimation with two exceptions:
- A parent issue with sub-issues should have an estimation just for the parent issue or the sub-issues, not both!
- If an active issue introduces a new bug, then the bug should have an estimation of 0*.*** This indicates a lack of developer testing and thus should be interpreted as an issue dept.
- Make sure no new issue is added to the active cycle unless it’s absolutely necessary. Don’t hesitate to inquire and ask why we need the new issue when it happens. If it’s essential to add a new issue (e.g. a high-priority issue that we cannot postpone), another issue with a similar estimate must be removed from the cycle. So that the team doesn’t over-commit! Each developer should have no more than 80 estimates.
- Retrospectives:
- Evaluate how the cycle went, specifically around the team dynamic, processes, and tools. A visible cycle board might be helpful to remind the team what went right or wrong.
- Moderate the retrospective. Encourage the team to speak about their minds on how the cycle went. Don’t hesitate to remind them this is not a check-in but just an overall review of the cycle.
- Keep meeting notes to keep track of areas for improvement and action items for future cycles.
More Reading