Time-constrained iterative workflow


July 8, 2024

We take inspiration from some aspects of Agile Software Development and Scrum, especially this idea of time-boxed periods (“iterations”) of work that follow a specific pattern and process for incrementally building or improving things. The reason we don’t completely use Agile or Scrum workflows is because these workflows generally don’t fit well in more academic and research environments. Scrum and Agile often assumes that:

However, often in academic and research settings, these assumptions are not relevant or applicable. For instance, often everyone is or may be involved in multiple projects. Or we have a broad and diverse range in technical skills around software development practices, often because research and academic environments don’t foster nor support nor are aware of these types of skills and knowledge. All of these impact how effective an Agile or Scrum workflow are in these environments.

Based on these inspirations, an iteration for us follows a general sequence of steps.

Future iteration planning

Team lead sets everything up for the next two or three iterations.

  • Will create an iteration within the main “Team project planning” board (which are all listed here, which is found in the Settings in the board.
  • Will write the title of the iteration as the goal for it, while keeping the goal focused, small, achievable, and considerate of the time we have available.
  • Will add the main tasks to achieve the iteration goal to the board.
  • Will plan iterations so that they either end on a major holiday or are right in the middle of it. If possible, don’t plan the start of iterations a few days before major holidays start.
  • Will plan and decide on how long the future iterations should be (can range from 2-6 weeks, but prefer shorter iterations over longer ones). So far, we find that 3 week iterations work the best.

Start of iteration


We track our iterations’ progress and tasks on GitHub with this project board.

An iteration starts with a first planning meeting that is scheduled well in advance, for between 1-2 hours and (preferably) right after the previous iteration’s debrief and retrospective. Preferably this meeting is in person. The aim of the meeting to discuss and plan the specifics of the iteration.


A basic agenda for the meeting might be:

  • Assign a timekeeper.
  • Review and agree on the iteration aim and end date.
  • Review the list of tasks already listed.
  • Brainstorm and add any other issues as needed.
  • Assign a team member to each task.
  • Schedule the next iteration’s end and start meetings.

In general, only the team lead is required to prepare for the planning meeting. Before the planning meeting, the team lead will move any existing tasks (GitHub Issues) into the iteration that is relevant to the aim of the iteration. The team lead will also create any issues that are missing from the current list of issues. While making issues, keep them as small as is reasonable and as descriptive and targeted as possible.

Other team members can optionally review the aim and output of the iteration board, review the list of issues already listed, and write out any potential issues as needed to complete the iteration aim.

During the meeting, someone will share their screen (if virtual) and the team goes through the tasks on the board together. We’ll discuss and decide or agree on the iteration goal (the “increment” or “milestone”). If relevant, we can also brainstorm any other tasks that are needed needed to complete the increment or milestone.

As we discuss each task, we collectively assign team members to the issues. Assign only one person per issue so that the project board can be kept organized and so that each issue has someone who is responsible for them. Anyone can help with the issue though. When assigning and distributing tasks, keep in mind the team member’s availability and time constraints, including days/hours required for other projects and any upcoming days off.

We’ll review and agree on the number of tasks (aim for 5-10 per person), the priority label on each task (low, medium, or high), the aim of the iteration,
and the end date. We agree on and schedule the end date debrief and retrospective meeting, which should be approximately 2-3 hour and preferably before lunch, as well as the next iterations planning meeting (preferably on the same date, but after lunch to ensure a proper break before moving to a new iteration).

During the iteration

We have a guide that describes in a bit more detail in how we work on tasks during an iteration. In general though, throughout the iteration, we will:

  • Have our update meetings to discuss progress, next steps, and any struggles or barriers (with the work or the iteration/process), as well as to 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.
  • Work on our assigned tasks (generally focus on higher priority tasks first) and coordinate with others if need be (@ mention the people involved in an issue, don’t assign).
  • Add more issues if required. If the issue is relevant to the current iteration, then add it to the project board so that we can determine who will self-assign it during one of our meetings. If the issue isn’t relevant, don’t add it to the project board but to the relevant repository instead, and we will save it for future iterations to work on.
  • Plan for “knowledge sharing” / “code review” sessions as necessary, for instance to go over a new feature or tool used in a pull request. For the author of the pull request, they will need to do a bit of preparation before hand so that the session runs smoothly.

End of iteration


We track our iterations’ progress and tasks on GitHub with this project board.

The iteration’s end is a last meeting for a debrief and retrospective to discuss how things went. These are between 1-2 hours and are preferably in person. The time and place of this meeting will have been scheduled during the planning meeting.


A basic agenda is:

  • Assign timekeeper.
  • Demo (internally or externally) the progress of the iteration.
  • Evaluate the iteration aim.
  • Go over what we accomplished and how we felt we did (including struggles).
  • Do a retrospective.

During the debrief and retrospective meeting, we will:

  • Assign a timekeeper to keep us on track and so we avoid spending too long on any one topic.
  • Show off and (optionally) demo the output of the iteration all together as a team. We’ll assign someone to be responsible for showing or trying out the demo before the meeting.
  • (Optionally done occasionally, but strongly suggested) Include someone external (a potential user) to try out the product/demo and give some feedback.
  • Evaluate the aim and review whether we’ve achieved the aim.
  • Briefly go over what we each did during the iteration and how we felt we did. Include any barriers, struggles, or challenges that came up during the iteration here.
  • Do a “retrospective”, where we individually write down how things went (“keep doing” category) and what could be improved or removed (“stop doing/improve on” category) in the process. The retrospective should ideally be done in a collaborative “note-taking/post-it notes” system (Figma is really nice for this). These notes will be collected into topics and we will add action items to each of the topics. The team lead will add these action items to issues or posts on how we work.