4  During an iteration

Note

This guidebook is written following the diátaxis “how-to guide” style. And because this document reflects how we work in the Seedcase Project, it is living and constantly evolving. It won’t ever be in a state of “done”.

During an iteration, there is a variety of tasks related to the management and completion of the iteration that you and everyone else on the team can or should do. This document describes what those might be and how to do them. Most of this document is relevant to all members of a team, but some are specific to the team lead. These specific sections will be indicated with a comment like “if you are the team lead”.

4.1 Task priority order

If you are the team lead, after the iteration planning meeting you need to set a priority for each issue in the iteration. The priority is determined by how important or urgent the task is to the iteration aim. Keep the distribution of priorities as even as possible. If all items are high priority, then no item is high priority. And that doesn’t help guide the team to knowing what to work on next.

While issues themselves are given a priority, there is also a priority in overall tasks (not issues) you and the rest of the team should focus on:

  1. Respond to reviewer comments on your own pull requests.
  2. Respond to issues where you are tagged/mentioned (@).
  3. Review pull requests from others.
  4. Work on your assigned highest priority issues.
  5. Respond to comments and questions in issues, unless it is a discussion issue, where the assigned team member will seek out and request your comments.

4.2 Assigning issues

All todo items related to an iteration are put as issues on the board during the planning stage and many will be unassigned. Throughout the iteration, you should self-assign the unassigned issues that you would like to work on. Here are some guidelines for self-assignment:

  • Only one person (in general) should be assigned per issue, so that the project board can be kept organized and so that each issue has someone who is responsible for it. However, anyone can help with the issue.
    • If a given issue might need input or help from another team member, coordinate with them if need be by @ mentioning them in the issue instead of assigning them.
  • When assigning yourself issues, keep in mind your own availability and time constraints, including days/hours required for other projects or events and any upcoming days off.
  • Issues are given priority labels and, in general, try to self-assign higher priority tasks first.

Aside from assigning yourself to issues, if you see that something needs to be done, create issues as needed.

  • If the issue is relevant to the current iteration, then add it to the current iteration project board and others can self-assign as desired.
  • If the issue isn’t relevant to the current iteration, don’t add it to the current iteration project board but instead to the issue list/backlog board, and we will save it for future iterations to work on.

4.3 Tasks unrelated to the iteration’s aim

In general, tasks you work on during the iteration should support the overall iteration goal. However, there are times when you might need to work on tasks unrelated to the goal of the current iteration. For example:

  • Whenever a decision is made, create a decision post about it as near to the time of decision as possible (or before making the decision).
  • Whenever a team member learns something and feels like it would be useful to share with the team, create a learning post about it as near to the time of learning as possible.
  • If tasks from the previous iteration are “In Progress” or “In Review” at the beginning of a new iteration, finish them during the next iteration.

4.4 Meetings

Meetings are times when tangible work isn’t being done, but they are useful for brainstorming things, coming to a consensus or agreement on a decision, or for briefly updating others on progress. So as much as possible, limit the amount and time spent on meetings, and use them for what they are most effective for. Here are some guidelines for having meetings during the iteration:

  • Have brief but regular update meetings to discuss progress, next steps, and any struggles or barriers (with the work or the iteration/process), as well as to potentially present a demo of the progress made within the iteration.
  • Schedule multi-person impromptu meetings as necessary and as relevant for a given task or issue, for instance a code review meeting or a discussion meeting.
  • Plan meetings on knowledge sharing or for code reviewing when, for instance, a new and more technically complicated feature is added or a new tool is used in a pull request. For the author of the pull request, they will need to do a bit of preparation beforehand for the meeting so that it runs smoothly and is an effective use of time.
  • Be mindful that not all team members are automatically relevant for all meetings. Think about who might benefit or contribute before sending an invitation to the entire team.