2-week iterations - Our default process

2-week iterations - Our default process#

Out of date!

Many of the sections below are out of date, particularly those related to the Engineering team’s delivery workflow.

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

Helpful links

👉 Here’s a link to all 2i2c GitHub Issues that have been assigned to you

👉 Here’s a link to see all Pull Requests for which your review is requested

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 5 sub-processes to move work through the delivery workflow. Namely:

  • Refinement

  • Planning

  • Progress Update

  • Showcase

  • Retrospective.

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

Ensure the Refined 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 committments. We then size and assign the items that each team member will work on for the next iteration, and review items that require discussion and planning.

During the Iteration

Team members work on the items assigned to them at the iteration planning meeting. 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 asynchronous Slack stand-ups.

Last day of Iteration

By the end of the day, team members should have completed all of their items for that iteration. The iteration is closed off with a Retrospective to identify improvement opportunities.

Iteration Cadence

  • Default: Two weeks.

  • Funding-crunch: One Weekly.

1. Pre-planning and refinement#

Tasks in the backlog are continually added and refined asynchronously by the whole team, ready for Iteration planning meetings, which rely on having sequenced and prioritized tasks to be available in the board’s Up next column. The backlog is regularly culled of tasks that are stale, in a monthly Backlog refinement meeting

Backlog refinement meetings should aim to

  • Identify and remove tasks that are stale or obsolete

  • Identify and action tasks that are in the wrong status or priority on the board

  • Identify tasks that need further asynchronous refinement

Tasks should tie back to initiatives or contract deliverables, and the refined column should also function as a buffer of uncommitted work to pull from if needed.

Attendees of the Refinement meeting should include representatives from the following teams:

  • Engineering: for technical decision-making

  • Product: for product decision-making

Product Managers at the meeting should come prepared to represent and advocate for Business Development interests.

2. Iteration Planning Guide#

🗓️ Between Refinement and Planning#

A Product Manager will:

  • Add deadlines to issues that need them
    A Product Manager will ensure that any issue with a contractual obligation or expected delivery has a clear due date.

  • Mark contract deliverables with dates
    Use labels to easily identify Contract Deliverables.

  • Assign preferred sprint-end dates
    If a card is intended for the upcoming sprint, let a Product Manager know and they will mark it with this sprint’s end date.

  • Organize in ‘Up Next’
    A Product Manager manages and sorts cards in the ‘Up Next’ column for visibility.

The Team will:

  • Review open-source contributions
    Include relevant contributions and initiatives in planning discussions.

  • Advocate for priority cards
    Team members should speak up for issues they’re most invested in or want to lead. Reach out to a Product Manager in the days leading up to a sprint to discuss the priority of the issues you wish to champion:

    • First check that the issues you want to suggest are not already in the Up Next column and dated for the upcoming sprint.

    • Send a message to the PM at least one day prior to the planning session with a list of issues you feel need to be included in the upcoming sprint.

    • Please include as much context as needed for the PM to understand why these issues need to be in the upcoming sprint

    • The PM will take your suggestions under advisement and make a best effort to include them, but cannot guarantee that to be the case as other priorities and capacity will need to be considered.

🗺️ Roadmap & Initiative Review#

The Product Manager will:

  • Review roadmap tab for issues with dates

    • Pull in overdue items.

    • Reassign unrealistic dates to achievable ones.

    • Ensure no items lag behind without follow-up.

✅ Preparing for Planning#

The Team will:

  • Ensure issues are current

    • All team members should update and clean up any issues to which they are assigned prior to the planning session

    • Ensure the use of the Standard Definition of Done available in the General Issue template where possible (See “How are Deliverabled Structured”, below).

The Engineering Manager will:

  • Report on last sprint’s progress
    Add totals for:

    • ✅ Done

    • 📂 Open

    • ❌ Unplanned
      to the previous sprint’s Status Update.

📆 At the Planning Session#

The Engineering Manager will:

🔁 Sprint Review & Retrospective#

  • Review last sprint’s outcomes

    • Compare actual velocity vs. target

    • Document the status update

    • Identify questions or blockers on leftover cards

    • Incorporate retro feedback to adjust workflows

🎯 Define Sprint Goals#

The Engineering Manager will:

  • Establish sprint themes

    • Ask the Head of Product and the Technical Lead to share focus areas or big goals

    • Invite input from the whole team for broader context

The Team will:

  • Identify a “1” (low-effort card)
    Start with the easiest, quickest win for the sprint.

🃏 Committing Cards#

The Team will:

  • Sort Board by date

    • Focus first on items due or overdue before exploring the rest.

    • Make sure to check dated items in the Up Next, Refined, Upcoming and In Flight columns are not being left behind

  • Start from the top of ‘Up Next’

    • ✍️ Summarize each card for shared understanding

    • 🧠 Estimate effort using Planning Poker or expert judgment

    • 🙋 Assign responsible team member(s)

    • 🔖 Move card to Committed and tag with sprint iteration

  • Prioritize initiative-linked and Contract Deliverable tasks

    • Reinforce the importance of completing tasks tied to Initiatives in Flight and Contract Deliverables.

  • Ensure coverage of key categories
    Explicitly address:

    1. Contract Deliverables

    2. BD requests

    3. Incident Mitigation issues

    4. Platform Initiatives

    5. Service Initiatives
      before moving on to anything else.

  • Continue until reaching target velocity
    Adjust as needed to fill capacity without overloading.

  • Balance workloads

    • Review assignments for each member

    • Shuffle cards to prevent burnout or neglect

    • Add or remove cards to ensure smooth sprint flow

📊 Final Sprint Setup#

  • Ping anyone who was not able to attend the meeting and ensure they are aware of the tasks they have been assigned.

  • Update new sprint’s status dashboard

    • Include total points in Committed

    • Ensure visibility across stakeholders

Planning Outcomes:#

At the end of this meeting, we will have:

  1. A sized list of team deliverables that the team commits to completing within the iteration time box. These deliverables will represent work from:

    • 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. Owners assigned to resolve the 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.

Tip

This meeting provides us a golden opportunity to:

  • Not overwhelm any team member

  • Under-estimate our team’s total capacity and to provide room for unexpected work (e.g., support work)

  • Limit the amount of work in process across Engineering (system optimisation)

  • Ensure that we are focused on delivering the highest value work (value optimisation).

3. Progress Update (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:

  • What am I working on? This helps the team to understand their progress towards completing work towards their iteration goal.

  • What will I work on next? This ensures that we working on the “right things” and limiting unplanned work.

  • What am I blocked on, or what do I foresee could be a blocker? This provides an opportunity for team members to ask for help and surface issues that may prevent the team from achiving it’s iteration goal.

  • Have I learned anything that needs to be addressed by/shared with the group? This maximizes shared-learning across the team (e.g. Here’s a faster way to configure and deploy docker scripts from Kubernetes).

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

  • Work that has become stuck (or will become blocked)

  • Work that is unplanned or should not be started

  • Work that is urgent

  • People that need assistance (or ask for help)

  • Opportunities to pair/collaborate with team members to complete work.

4. Demo/Showcase (NOT CURRENTLY IMPLEMENTED)#

To be implemented.

5.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:

  • Thanks and Celebrations

  • Things That Went Well

  • Things To Improve

  • Actions (Items to take forward into the next sprint).

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.

    Note

    It is important to discourage “solutioning” at this stage.

  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:

  • Upcoming PS Initiatives represents high level initiatives waiting to be picked up, with highest priority towards the top.

  • PS Initiatives in flight represents high level initiatives that are actively being worked on, with highest priority towards the top.

  • Refined represents prioritized tasks ready to be worked, with the highest priority towards the top.

  • Up Next represents prioritized tasks that will be included into the upcoming sprint(s) with the highest priority towards the top.

  • Committed represents tasks we’ve committed to complete during the current sprint in the most recent sprint planning meeting. Each item should have at least one owner.

  • In Progress represents actively worked tasks.

  • In Review/Blocked represents tasks that need to be review before being marked as done or that cannot be completed without additional actions/support.

  • Done represents completed tasks to be celebrated and archived in the next sprint planning meeting.

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.

Note

We use the word “deliverable” loosely here - some issues may be more like tasks rather than an end-product. The important thing is that they have high-quality information and structure, clearly denote value, and are actionable.

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.

Contents