Skip to article frontmatterSkip to article content
Site not loading correctly?

This may be due to an incorrect BASE_URL configuration. See the MyST Documentation for reference.

2-week iterations with “Accountable Kanban” - Our default process

This section describes how our development team carries out its planning and day-to-day work.

Pull request workflow

See Merge and Code Review policy.

Team Iterations

The 2i2c team uses Iterations to coordinate with one another in focused cycles of work (referred to as our Iteration Cadence). Our team works in two-week iterations.

We rely on 4 sub-processes to move work through the delivery workflow. Namely:

These sub-processes are defined in more detail below.

Iteration cadence

Our team works in two-week iterations. Here is a brief overview of each Iteration.

Before Iteration

Product Management takes in input from the team and the business at large and ensures the Up Next column has ranked (prioritized and sequenced) work items

Beginning of Iteration

Iteration begins with our Iteration planning meeting.

In this meeting we discuss major accomplishments in the previous iteration, review past capacity commitments, and assess the velocity of the last iteration. We then size the items in the Up Next column which form the backlog of work for upcoming iterations, and review items that require discussion and planning.

During the Iteration

Team members pick up the first item of work in the Up Next column that they can help with. It’s up to each team member to judge how they can help, and to pick up work that matches their skills and expertise (The “Accountable” part of Accountable Kanban).

We use the Iteration Board to coordinate our activities during the iteration. We provide updates about what we’ve been up to, what we’re doing next, and where we need help via regular twice-weekly stand-ups. as well as asynchronously through Slack.

Last day of Iteration
By the end of the day, team members should aim to have closed the majority of the tasks they had with the “in progress” status. The iteration is closed off with a Retrospective to identify improvement opportunities.

1. Pre-planning and refinement

Tasks in the backlog are continually added and refined asynchronously by the whole team. Product Management takes tasks from Refined and places them in order of priority in the Up Next column. Tasks that tie back to initiatives or contract deliverables are normally given priority. The backlog is regularly culled of tasks that are stale, a process that is mostly done asynchronously, with the occasional backlog refinement meeting called by Product Management as needed.

2. Iteration Planning Guide

🗓️ Before Iteration Planning

A Product Manager will:

The Team will:

🗺️ Roadmap & Initiative Review

The Product Manager will:

✅ Preparing for Planning

The Team will:

The Engineering Manager will:

🔁 Sprint Review & Retrospective

The Engineering Manager will:

The Tech Lead will:

🎯 Define Sprint Goals

The Engineering Manager will:

📊 Final Sprint Setup

Planning Outcomes:

At the end of this meeting, we will have:

  1. A sized list of team deliverables that are in order of priority in the Up Next column and are broadly understood by the team.

    • Grant/Funding

    • Partnerships

    • Product Roadmap

    • Support request

    • Internal Engineering

    • Upstream community

  2. Identified and shared the core risks impacting the deliverables. NB: The meeting will not be used to brainstorm solutions to resolve the risks.

  3. For specific high-effort or complext tasks, Owners may be assigned instead at planning instead of letting anyone pick those tasks up during the iteration. Owners are usually assigned to resolve different risks. These individuals will create working sessions and coordinate the necessary domain experts who will be responsible for resolving the risks. NB: The owner is accountable to ensure the working sessions happen. They are not responsible for the actual solutions as this may belong to separate domain experts. A deliverable cannot be committed as part of the iteration if there are dependencies with other teams AND those other teams have not committed to completing the work within the current iteration or if the work was not previously completed in an earlier iteration.

3. Standups for progress updates (and blockers)

This is a short, synchronous, alignment meeting (sometimes referred to as a “Standup”). It occurs on Tuesdays and Thursdays, and is designed to help us coordinate and realign ourselves around the work.

Each sync ensures team members focus on the most important tasks and allows the team to pivot and self-organize when unforeseen changes occur. It helps catch and address unplanned challenges, work, and risks, providing a way to transparently discuss any issues that may hinder achieving our iteration goals.

Guidelines for the standup

These are guidelines for the standup. Ideally, these meetings should not extend beyond 15 minutes and each person will answer these questions:

This is done in conjunction to using the board to identify:

4. Retrospective/Continuous improvement

At the end of each iteration, the team holds a retrospective meeting to reflect and identify actions to improve the team’s ways of working and delivery process. The retrospective is the process through which the team achieves continuous improvement for all their other processes. When done effectively, this event will enable us to make data-informed decisions regarding what key changes to adopt, amplify or discard from our processes.

The Duration of the Retrospective

The retrospective is 45 minutes long and is usually held on the last day of each iteration. It is held at a time to maximise attendance from the engineering team.

On rare occasions, when the team experiences duress or unpredictable and disruptive events, they may choose to have a specific retrospective to learn from those events.

The Roster for Facilitating Retrospectives

There is a Google Sheet in the shared team drive that determines who will be facilitating each retrospective meeting (as well as sprint planning and backlog refinement meetings). Members of the engineering team are expected to self-nominate for this role because it is their improvement process.

Retrospective Tool

The team uses an EasyRetro board to collect cards representing feedback concerning the last sprint. There are columns for:

This template can be changed by the facilitator. There are many different template formats and the facilitator should choose one that is most appropriate for the team’s need.

EasyRetro user account

We have a paid Team subscription for EasyRetro, to make it easier to facilitate retrospectives. The user account is admin@2i2c.org. The credentials are stored in our shared BitWarden account.

The General Format of an Iteration Retrospective

The retrospective meeting follows the below outline.

  1. Identify a facilitator.

    The facilitator has the responsibility to:

    • Ensure that their is psychological safety in the meeting.

    • Ensure that the meeting isn’t used as a blaming/ranting/finger pointing session.

    • Share the Retrospective Prime directive with the participants.

  2. Set the context for the Iteration retrospective.

    This involves explaining the period under observation, which process(es) we are trying to improve and what has been achieved by the current process. This could involve reviewing the ‘Done’ column in The Iteration Board.

  3. Review the previous retrospective actions.

    Reviewing previous retrospective actions involves:

    • checking if the team completed all of the previous actions that they committed to

    • noting how many actions were completed

    • briefly discussing if the action has had the intended impact.

    Retrospective actions are stored in the team’s Sprint board and are tagged with the Retro action label.

  4. Set aside time for the team reflect and capture input on cards.

    Team members need ample time to reflect on their work, interactions and the effectiveness of process from the past iteration. This time will vary based on the size of the team, the duration of the retrospective and temperament of the team.

    This duration of this step is usually between 5 - 15 minutes.

    In some cases, the team is invited to pre-populate the board with input before the actual retrospective.

  5. Thanks and Celebrations

    Ultimately, the team needs to find a way to celebrate each other. In some cases, this may be simply the team reading the cards themselves or the facilitator doing this.

  6. Create shared understanding on Went Well, and To Improve columns.

    During this time, the facilitator groups the cards into themes (in the form of hashtags), potentially merging similar cards.

  7. Discussion amongst the team on the To Improve items.

    For cards that are unclear, the facilitator should encourage the person that wrote the card to provide context. Team members can ask clarifying questions of each other.

  8. Voting on the To Improve items.

    The team can then vote on which To Improve items they think are the most important.

    For example: Each member gets 3 votes that they can distribute as they see fit, e.g., give all 3 votes to one item, 2 to one item and 1 to another, or 1 vote for 3 items.

  9. Identify actions.

    For the top-voted actions (limited to only 2 or 3), the team generates some concrete actions to try and resolve the issues. These are captured in the Action Items column.

  10. Close the meeting.

After the meeting, the facilitator is responsible for converting the Action Items into GitHub issues to be put in the sprint board’s backlog column, and then clearing the retro board.

When should the Retro Board be Populated

Team members are expected to try populate the board ahead of time to the extent that what remains could be populated in five minutes just-in-time during the meeting.

How do Generated Actions move into and get committed to the Team’s Next Sprint?

The general rule is that actions are also work and should be refined and prioritized like any other work.

The Iteration Board

The Iteration Board is a place to keep track of the Deliverables and tasks our team intends to work on for a two week iteration.

The board is a GitHub Projects board that is populated with tasks during the teams Iteration Planning activity.

The team’s goal is to complete all items on the Sprint Board by the end of the Sprint. This is a team commitment - while one person may be assigned to a deliverable, we all commit to working together to get the work done.

The Sprint Board is broken down into different columns that represent the team’s delivery workflow. The team owns the design of this workflow and should change the workflow process to best suit their way of working and to optimize for sustainable delivery.

The current queues of work represented by the board are:

Deliverables and work issues

Deliverables represent incremental amounts of value we can deliver to a particular stakeholder. They are encoded as GitHub Issues and updated over time as we learn more about the particular deliverable. Most issues in our repositories are deliverables, in varying states of readiness.

How are deliverables structured?

There are a few special sections of a deliverable issue. Not all of them are strictly required, but are particularly useful for more complex or long-lasting deliverables.

See this Github Issue template for an example of a deliverable’s structure. Below are some major sections that are common:

Context

The top comment of a deliverable has meta information associated with that deliverable. This includes background information, user stories, task lists, etc. The top comment should be frequently updated by anybody on the team with relevant information to add. Do not hesitate to update somebody’s top comment with new information, even if you didn’t open the issue (though you’re encouraged to leave a comment noting what has changed!).

What we need to do

What is the intended aim of the deliverable? This should be in the form of user stories or a thorough description that explicitly define the stakeholders that care about a deliverable, and why.

Definition of Done

Use task lists encode discrete steps to take in order to complete a deliverable. All deliverables should have either a set of concrete steps to take to meet the deliverable, or at least one task with the acceptance criteria for when the deliverable will be complete. Task lists should be in the top comment of the deliverable, and are encoded as markdown tasks lists (e.g. with - [ ]). Task lists should be updated over time as we learn the steps needed to close the deliverable. For more complex deliverables, these tasks may be what goes onto the Sprint Board, rather than the deliverable itself.

We use a Standard Definition of Done to guide the creation of any issue’s DoD, suggesting a selection of the following steps to delivery:

- [ ] The feature/service is technically complete
- [ ] The feature/service been tested with one or more users (if applicable)
- [ ] The feature/service been deployed to a production cluster
- [ ] The feature/service has been shown to be replicably deployable
- [ ] The feature/service is well documented, and the documentation is accessible for the target user base
- [ ] The feature/service has been added to our product menu (if applicable).
- [ ] Lessons learned have been documented
- [ ] The feature's availability has been communicated to Sales
- [ ] The feature has been communicated to our communities

The #product-and-services Slack channel

The #product-and-services Slack channel is a place for the P&S team to coordinate, plan, and discuss their work.