Skip to content



We work in two-week sprints. While each cell has its own board, backlog and sprint, they are all held in sync on their start and end.

Here's an overview of the process highlighting typical milestones and activities. For a full detailed description of the steps see the Sprint Planning Process.

Day of Sprint
Day 0 (Monday) Last day of the previous sprint's planning process. We use the SprintCraft to review cell member's time allocation and ensure everyone has enough work and not overcommitting. We also collectively make sure we're staying on track with each client's monthly budget and each epic/project budget.
Day 0 or 1 Each cell member should review every ticket they have in the sprint, to confirm the due date, plan when/how to approach the work, coordinate with the reviewer for time-sensitive reviews, etc.
Days 0-4 Development - each team member works on their tickets and code reviews. Tasks move from left to right until completion on our JIRA tracker.
Day 7 (Monday) Each cell member shares a mid-sprint update. It should communicate if everything is going smoothly or if there are tasks at risk of not being finished — cell members coordinate with each other to help.
Days 7-11 Development continues.
Day 10 (Thursday) Each epic owner posts an epic update, which includes creating and prioritizing all tasks from that epic that their cell should work on in the upcoming sprint.
Day 11 (Friday) Cells collaboratively and asynchronously refine and estimate tasks complexity. Once done, they assign tasks and reviews to themselves.
End of day Friday is the deadline for creating and assigning stories to the upcoming sprint, and is also when the asynchronous refinement session is closed.
Day 14 (Monday) Depending on their timezone, some cell members may have some time on Monday to finish up development or work ahead before the new sprint starts. They also share a end-of-sprint update.

Additional Information & Tips

For everyone (all roles)

  • In general, "work from the right" - it's better to finish a task that's already in progress than it is to start a whole new task. This reduces context switching, which will help get things done more quickly. With that said, if you are blocked on a task, move on to another task, until unblocked.
  • Daily, use the Tempo time tracking on the Jira board to record the time spent on each task and update each ticket being worked on once finished on it for the day. Even just a quick summary or sentence of where you're at with the task is useful to your reviewer.


  • All tasks are split up into epics, and each epic has an "epic owner. Before Day 1 (Tuesday), everyone asynchronously assign each story in the upcoming sprint to a developer and a code reviewer.
    • The epic owner is responsible for making sure this happens for each story in their epics that must happen in the upcoming sprint. For stories that don't have an epic owner, either the tentative assignee (if there is one already) or the person who reported the ticket is responsible for doing this; this is also documented in our sprint bot, Crafty.
    • Epic owners should also check the SprintCraft for the upcoming sprint, ensuring that the tasks the team plans to take on for the upcoming sprint are in line with each client's budget and each epic's budget.

During the sprint

  • Take a look at the current sprint board. There are filters at the top such as My Issues, My code reviews, and your name, which can be toggled to show only issues relevant to you.
  • Drag a task from column to column on the sprint board to update its status as you work through it. The various statuses/columns are described below. Tasks move from left to right until completion.
  • In general, "work from the right" - it's better to finish a task that's already in progress than it is to start a whole new task. This reduces context switching, which will help get things done more quickly; it also demonstrates reactivity to upstream reviewers (which pushes them to be reactive too).
  • Use the Tempo timekeeping system built into our JIRA board for tracking the time you spend on each task.

Sprint Planning Process

Since we're a remote team spread globally around the world, having synchronous meetings might not be fair for different members because it's difficult to find a decent time for everyone. Therefore, our sprint planning process is asynchronous.

Planning for a given sprint is done asynchronously, with the steps happening during the previous sprint. So, in any given sprint, one of the tasks everyone has is to plan for the following sprint.

In order to guide you through planning your sprint, a sprint planning checklist is already created for you at the start of each sprint.

In the following sections, you can find additional details for some of the steps in the sprint planning process.

Sprint planning checklist

As mentioned earlier, everyone is responsible for planning their own sprint. In order to facilitate that, we have a sprint planning checklist for each member to follow to ensure they haven't missed any of their responsibilities.

All sprint planning checklists are created based on a single template. When the sprint starts for a specific cell, a bot creates the necessary checklists for all its members.

The tasks are organized according to their deadline. In addition, you can filter them based on your cell responsibilities, such as firefighter, sprint planning manager, discovery duty, epic owner, etc... Accordingly, the checklist should be your guide for planning your sprint.

A good habit is starting off your day by finalizing your sprint planning responsibilities for that day in the sprint. This would ensure that you're always on top of your sprint planning responsibilities, and a well planned sprint is a good one!

You can find your own sprint planning checklist under your cell's workspace, named in the following manner: <Cell Abbreviation>.<Sprint Number> - <Name>.

Reserved time

Sprint planning is an essential part of our job. It is a task that extends through the whole sprint.

Although we could create tickets for every member to block enough time for sprint planning, that wouldn't be manageable, and that would pollute the sprint board too.

The goal is to let everyone enough time to plan their sprint properly to reduce burnout, stress, and other negative factors. While pursuing every opportunity to give the best quality and more features to our clients, it can be easy to treat this buffer time as a "safety buffer" where other client tasks can fit, but please do not do that. This time is reserved for you and those tasks that must be in the next sprint.

Of course, if the next sprint is planned and nobody needs help with its tickets, and there are no fires, you are welcome to work ahead, but please keep the reason for this buffer in mind.

The reserved time is 8 hours at the moment, but it may change soon.

Tentative assignees

To ensure that tasks lined up for the sprint are all actively being taken care of, from the beginning of sprint planning, some tasks are tentatively assigned by their creator. To show the tentative assignment, these tasks are flagged in Jira (they appear in yellow in the backlog).

The tentative assignee isn’t meant to be necessarily the person who will be actually working on the task. Like for PR reviews, the goal is to ensure proper focus and avoid dilution of responsibility, so we need one specific person assigned to each ticket to do that review early on, even if the actual assignee changes later.

The assignment is done without considering size/availability, since the tickets aren’t yet scoped or estimated. The tentative assignee is merely the person who will be responsible for finding the final assignee, and getting the task through the planning steps in the meantime, such as reviewing the task description.

The tentative assignee is responsible for reassigning and/or rescoping the tickets before the sprint starts. Note that if no action is taken, by default the tentative assignee will become the actual task assignee when the sprint starts.

Estimation session

We each estimate the complexity of the tasks for the upcoming sprint in terms of "story points". The sprint planning manager creates the sprint estimation session in Jira. An email with a link is sent out when the session opens.

We use story points as a shorthand for agreeing about the complexity of a task. Story points are meant to be a relatively objective measure of "complexity", and not necessarily indicate how long it would take any particular developer to do.

For each task, you should:

  • Read through the description.
  • Decide whether you can take it.
  • If you do want it, it's ok to spend a bit more time investigating.
  • If you have questions, put them in comments on the ticket.
  • Once you understand the task, assign points as described in the process section.
  • Use the "estimate comments" box to qualify estimates.
  • Choose ? if you have no idea how many points.
  • A little green (/) will appear next to your picture up top when you are done.

    • We use a fibonacci scale for story points (please see task workflows for more detail on story points for different types of tasks).
    • If anything about the task or the acceptance criteria is unclear, post a question as a comment on the task and try to work with the epic owner (or the reporter if there is no epic owner) to get it answered before the meeting. Note that during the asynchronous refinement sessions, any comments/questions posted in the estimation session will be lost once the refinement session ends, so it's preferable to post questions on the tickets themselves.

Complete the estimation session by Friday. Stay conscious of time budgets and try not to log more than a few minutes per task to do these estimates.

Task insertion

The following process applies when someone wants to add a ticket to the sprint after the Thursday end of day deadline:

  • If the ticket replaces another ticket already in the sprint, or is split out from one: explicitly reference the ticket being replaced or split out from in the task description, and ping the sprint planning manager for confirmation.
  • Otherwise, place the ticket at the top of the stretch goals, and ping the sprint planning manager to inform of the desire to include the ticket in the sprint if possible. There would not be any guarantee of such an inclusion, but once the sprint is fully ready (ie, all the tickets in the sprint are ready and all the other verifications before the start of the sprint have been completed, including ensuring nobody is overcommitted), then the ticket can be considered for a sprint insertion if someone still needs work. This is handled the same way we would treat a ticket that we want to add in the middle of a sprint.
  • No other exception. A sprint insertion has to follow either of these paths, or it will be moved to the next sprint or the stretch goals.

Sprint updates

These are text and video updates posted in a dedicated "sprint updates" forum thread for the cell, which is reused between sprints. There are two.

Mid-sprint updates are text-only posts on the first Monday. In this update the cell member will say how their sprint is going, and whether they anticipate not being able to finish some of their stories, or finishing early. And, optionally, the cell member give kudos to others' work that deserve positive feedback. They are a way for the cell to get mid-term feedback on the sprint progress and anticipate blockers.

End-of-sprint updates are video posts on the second Monday. They are a way for us to keep a regular occasion for everyone in a cell to see & hear each other directly on video, rather than switch to 100% textual. They also include an optional text component, that complements the video format, if necessary.

The video recording should have 1 to 2 minutes maximum on Loom (credentials for core members) or using the software of your choice such as OBS Studio:

  • Share both your screen & camera, and name the video Sprint X - <Cell> - <Your name> with X being the number of the sprint finishing
  • If you are a core member using a Loom video, copy the link from the "Send your video" box on the top right of the Loom video page, and place it on a line by itself to ensure discourse shows the video inline.
  • If you create your own video, upload it to the Sprint update videos folder, and use an iframe to display the video inline in your post:
    • <iframe src="[hash]/preview" width="640" height="360" frameborder="0" allowfullscreen></iframe>
    • Note that it might be necessary to disable the enhanced tracking protection from Firefox on to play videos embedded this way.
  • [Optional] Include a text update below your video - for example to highlight points that shouldn't be missed, or provide links to elements you mention in your video.

Present the following points in your video update:

  • If a newcomer is scheduled to join this week, ensure you've created a quick introductory video of yourself and stored it under your cell in OpenCraft Shared Drive > Meeting videos > Team introductions. Provide your name, how long you have been with OpenCraft, your current location, and an interesting fact about you.
  • Some of your work, in a mini-demo/presentation of what you did during the previous sprint, mentioning any major accomplishments, interesting tickets, lessons learned, or problems encountered that are worth sharing with the team. What has been accomplished, what went well, what went not so well, and the reason for any spillover. Don't just show your Jira board though -- people can already go see this by themselves.
  • Any upcoming vacation if you have some in the upcoming sprint.
  • [Optional] Giving kudos
  • [Optional] Pointing to announcements and discussion started on the forum, introducing them orally when it’s useful.
  • [Optional] If you would like to make an extended presentation or tech demo, which doesn't fit in the 2 minutes of your weekly update, record a separate second video, which you will post in the forum in a dedicated thread. Mention who the intended audience is (the rest of your cell, the whole company, etc.), ask for questions explicitly and come back to the thread regularly to answer them.
  • The sprint firefighter with the rotation on the first week of the upcoming sprint reminds of the theme and time of the social chat they organize this week

Social chat

With asynchronous planning agenda the cells and its members don't get to interact with each other in videocalls regularly. To keep an occasion to do that, and actually make those interactions nicer, we are setting up regular social chats. They are a less formal and utilitarian setting, and are there more to interact with each other in an informal setting, and are optional.

  • They are organized by rotation, and happen every sprint during the first week - every core team member organizes one in turn for their cell, and open to anyone from any cell. We use the firefighter rotation for this, the firefighter for the first week of a sprint posts a topic of their choice and a time (during that same first week of the sprint).
  • Any topic goes, be creative! It doesn't need to be about work (shouldn't be about work?): games, teaching how to prepare a cocktail or recipe, participants showing an interesting place in their neighborhood, etc.
  • The organizer describes the event in a dedicated "Social chat" forum thread for the cell, reused each sprint.
  • The organizer creates a calendar event on the cell's calendar at the time of their choice, and invites all the cell's members as optional attendees. The calendar invite should include:
    • The description/agenda of the event
    • A Zoom meeting URL
    • A link to the corresponding forum post
    • A link to the task where to log the meeting time
    • A mention that the meeting is optional (nobody except the organizer should feel forced to attend, and due to timezones & schedules not everyone will be able to attend every meeting)
  • The 30 minutes are logged on a dedicated task by participants. The organizer creates the task dedicated to a specific meeting when organizing it, including it on a "Social chat" epic, with the "Meetings" account set.
  • Participants can stay longer than 30 minutes at the event if they want to, or attend multiple events from multiple cells, but the time logged is timeboxed to 30 minutes overall. Anyone can leave at any time.

All-hands meetings and tech talks

From time to time we get together and do tech talks, to share knowledge and as an opportunity to meet members of the other cells. Note that a tech talk can also be contributed asynchronously using the video recording at the end of any sprint.

An all-hands meeting will be scheduled when there's something we want to discuss at the team level, or when there's a tech talk. To schedule a tech talk, create a ticket in your own cell to prepare it, then discuss in the tech talks thread a date that works for all cells (it must be on the same day as a mid-sprint update).

Sprint Retrospectives

Each cell performs a retrospective every sprint. The purpose of the sprint retrospective is to allowed continued improvement on our processes and methods by creating dedicated time for reviewing how each sprint went, and how things might be improved.

Near the end of each sprint, every member is expected to go to the Sprint Retrospective Document and add things which need to be improved and things that went well to their cell's worksheet. After rolling over to the new sprint, the Sprint Manager takes these items and adds them to the cell's running forum thread on sprint retrospectives. These threads are named 'Sprint Retrospective - Cell Name Here'. (Note: At present these threads are private threads, and may not be visible if you are not a member of OpenCraft and logged in.)

In the forum post, the sprint manager may mention the things that went well, and then will mention the things that need improvement. If there are more than two things which need improvement, the Sprint Manager creates a poll for members to vote on to determine what the cell thinks is the highest priority to address. During the sprint, talks begin between on how to address these items, and tasks are created and scheduled as necessary by the participants.

The Business Cell Sprints

The 'business cell', consisting of meta-operatives working on things like billing, sales, and marketing, currently meets synchronously for one-week sprints.

In time, this cell may move to an asynchronous cadence more in line with the development teams, however for the moment it closely mirrors the synchronous sprint planning of old.

Preparing for the Business Cell Sprint Meeting

Ahead of the business cell sprint planning meeting, look through all of your current tasks and make sure any which have not been updated to their most current state are updated.

Then, look in the backlog. Consider any spillover you may have, and look at the upcoming sprint. If it does not exist, create it. Put any tickets you anticipate working on into the new sprint to reduce time spent planning during the meeting.

Complete the Sprint Retrospective process, adding in items as you see fit to the business cell worksheet. Log your time here.

Business Cell Sprint Planning Meeting Agenda

The sprint meetings have the following agenda:

  1. Each member gives an overview of what they worked on this sprint, and any items that spilled over and will affect the next one, as well as reasons for the spillover.
  2. Close the current sprint, setting all still open tickets to move to the next sprint.
  3. With the team, look over the items in the upcoming sprint. Take a moment to verify:
    • Each team member acknowledges the workload they're committing to.
    • All tickets have story points, assignees, and reviewers.
    • Ask about vacation or other reasons for reduced capacity. Will this affect the work being taken on?
    • If there is spare capacity and no intentional reduction in hours, work with the team to pull items from the backlog until capacity is reached.
  4. After confirmation on all items above, start the next sprint.
  5. Any final notes/announcements/kudos.

Business Sprint Video Updates

Like the development cells, the Business Cell members are expected to post video updates to keep the team at large abreast of new developments in this thread. However, since business cell members have one-week sprints instead of two-week sprints, they are only expected to post these every other sprint, at the same time as development cell members post theirs.

This is to make sure that time can be scheduled to run through all updates in one go to reduce context switching among team members.