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#
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#
The Refinement meetings prepares the Iteration board for the Iteration planning meetings, which relies on having sequenced and prioritized tasks to be available in the board’s Refined column.
Backlog refinement meetings should drive:
creation of tasks into the sprint board’s backlog column
promotion of tasks into the sprint board’s refined column
prioritization of task in the sprint board’s refined column
Tasks should tie back to initiatives, 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
Partnerships and Community Success: for community/grant decision-making.
2. Iteration Planning#
The team conducts a synchronous iteration planning meeting for 60 minutes at the beginning of each iteration.
The goal of this meeting is to synchronize with one another and commit to work to do during the iteration that gets us closer to achieving the initiatives objectives.
Planning Outcomes:#
At the end of this meeting, we will have:
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
Identified and shared the core risks impacting the deliverables. NB: The meeting will not be used to brainstorm solutions to resolve the risks.
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).
See the Sprint Planning issue template for the agenda / structure of these meetings.
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.
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.
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.
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 actionlabel.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.
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.
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.
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.
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.
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.
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:
Backlog represents tasks pending refinement as driven by backlog refinement meetings.
Refined represents prioritized tasks ready to be worked, 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? (OUTDATED)#
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:
- Top Comment
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!).
- Benefit
What is the benefit for completing this deliverable? This should be in the form of user stories that explicitly define the stakeholders that care about a deliverable, and why.
- Tasks to complete
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.
The Team Backlog (OUTDATED)#
Click here to go to the Team Backlog.
The Team Backlog is a GitHub Projects Board with a list of Deliverables and tasks across all of our active projects. This represents the work that the team is planning to do in the near future. These items adhere to the following principles:
The order of items should be roughly according to priority, with higher priority items at the top of lists.
Items on the board should have a status that signals whether they are ready to work or need more refinement before working.
If an item has multiple components or would otherwise take longer than a sprint to complete, create new issues as sub-tasks, and add them to the Sprint Board.
Assigning to an issue (OUTDATED)#
Only assign a backlog issue to somebody if it is actively being worked on. We assume that once somebody is assigned to an issue, it is part of an active iteration. Note that all issues on our Iteration Backlog should have somebody assigned to them.
Our definition of “Work in Progress”
Because issues that are actively being worked on must have somebody assigned to them, we use “the issues that have somebody assigned to them” as our definition of Work in Progress.
Backlog item limits (OUTDATED)#
Our goal is to have backlog items that roughly cover the next 3 iteration cycles. We should not have more backlog items than this amount.
You can estimate the number of items on the board at any one time by assuming that each team member (at 100% FTE) can accomplish about 2 items per sprint. You can then calculate the rough number of items on this board with the equation:
n_team_members * 2 (items per sprint) * 3 (sprints on the board)
So if we have 5.5 team members available (if one of them is at 50% FTE), then the team backlog should have around 5.5 * 2 * 3 = 33 deliverables on it.
Adding backlog items#
We should add items to our team backlog when we have capacity to do the work in the next 3 sprints, and when those items are ready to be prioritized over all the other work that we could do (e.g., all issues in our repositories and encoded in project backlogs).
Tip
It can be difficult to keep track of issues across all of our repositories, so using a Project Backlog can be helpful to track longer-term planning for a specific project.
To add an item to the backlog, take the following steps:
Look at the team backlog to make sure that it has capacity to absorb a new item.
If it does not have capacity
Consider adding it to a Project Backlog or leave it in the issues of a repository. We can always get to it later.
Choose whether you wish to remove an item from the backlog in order to make space. Use your best judgment about whether this is the right thing to do, depending on the priority of the backlog items that are already on there.
Place the new backlog item in the appropriate location, according to its perceived importance and urgency.
How to prioritize backlog items#
It can be difficult to prioritize backlog items, and is ultimately a subjective decision. These criteria can be used to help guide your actions:
Impact: How impactful will it be to resolve this item? Will it affect many users or be particularly useful?
Urgency: How important is it that we resolve this item quickly? If it is lower impact, but urgent to accomplish, we may nonetheless wish to prioritize it.
Effort: How many moving pieces does this item have and how much deep thinking will it take to resolve? All else being equal, we should prioritize backlog items that are easier or faster to accomplish since this will be more bang for our buck. This is obviously very subjective, so is probably best-estimated when there’s a candidate person to work on an item.
Working on backlog items#
Backlog items are ready to work when they have enough context and tasks so that a team member can begin making progress towards closing them. This doesn’t mean that we know all of the tasks needed to complete the item, but that there’s enough information to begin work. [1]
The team picks up work associated with a backlog item via our Sprint Planning meeting. In this case, there are two options:
Add the item to the Sprint Board. If an item is scoped tightly enough that it can be completed within one sprint, then add it to the Sprint Board and complete it in a sprint.
Generate issues from tasks and add them to the Sprint Board. For items that are more complex and require tasks that would take more than one sprint, use the Task List in the issue to generate new issues for use on the Sprint Board.
Tip
You can use GitHub’s task issue tracking features to keep track of tasks associated with an issue.
As work is done towards a backlog item, update the top comment of the issue with new information and tasks. Each parent issue is the Source of Truth for all work associated with it (instead of, for example, an issue created as a sub-task for that item).
Tracking upstream issues#
In some cases we want to do work in an upstream repository or project. To do this, add upstream issues to our Team Backlog as we would add any other issue.
How to keep track of projects#
Longer-term projects are generally more complex and may be made up of many actions and deliverables to accomplish. There is no official way to track long-term projects within 2i2c, but there are a few patterns that may be useful to do so, described in this section.
Tracking issues#
The simplest way to track longer-term efforts is with a Tracking Issue. This is a GitHub Issue whose job is to keep track of many actions and deliverables over time that are needed to close the issue. They are generally encoded as Task Lists in the issue’s top comment. Each item in the list tends to be a deliverable, and can be converted into its own GitHub Issue (e.g., to put on the Sprint Board) as-needed.
Project Backlogs#
For more complex efforts, it can be useful to create a Project Backlog. These are GitHub Projects boards that contain all of the deliverables that will complete a given project. These are often organized into a few columns, representing the state of each deliverable. Here is a common column structure:
Needs Discussion/Refinement: Deliverables that are high-priority but un-refined. Our goal should be having discussion and doing research in order to get these deliverables ready for work.
Ready to Work: Deliverables that are well-scoped and have a clear path forward, and are thus ready to implement. As deliverables in In progress are completed, we should replace them with deliverables from this column. Generally speaking, deliverables near the top have higher priority than those at the bottom.
In progress: Deliverables that we are currently working towards. This means that they should be added to the Sprint Board to track its completion.
Blocked: Deliverables that require another action or delivearable from the 2i2c team to complete before they can move forward.
Waiting: Deliverables that require another action from a non-2i2c team member before they can move forward.
Done: Deliverables that have been completed. We should close these issues and celebrate the improvements that we have made!
The #engineering Slack channel#
The #engineering Slack channel is a place for the engineering team to coordinate, plan, and discuss their work.