Please find below the description of the process for sprints. While it might sound a bit convoluted, it's pretty simple in practice. We work in two-week sprints. Each cell has its own board, backlog and sprint, but they are all held in sync.
|Day of Sprint|
|Day 0 (Monday)||Each cell holds a sprint planning meeting to do a final review of the plans for the upcoming sprint, and start the sprint. We use the Sprints app to plan our team's time (that everyone has enough work and nobody will be overcommitted) and to collectively make sure we're staying on track with each client's monthly budget and each epic/project budget.|
|Day 0 or 1||Each developer 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 holds a mid-sprint meeting to ensure everything is going smoothly, and discuss how to help with tasks that are at risk of not being finished by the end of the sprint.|
|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 developers may have some time on Monday to finish up development or work ahead before the new sprint starts.|
- 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."
- Near the end of each sprint, in preparation for the next one, the team
will do an asynchronous "refinement" session. This means that we each
estimate the complexity of each task in the upcoming sprint in terms
of "story points". The person in the cell responsible for the sprint planning is the one who
starts this refinement session and invites everyone to it.
- 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.
- 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.
- Likewise, before the Monday planning meeting, everyone works
to 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 Jira bot Crafty's code
- Epic owners should also check the Sprints app 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.
- We have a meeting on Monday via video chat. There we review the refinement and assignments
for the upcoming sprint (please see the sprint planning agenda
for details of this meeting).
- The meeting link is in the calendar invite.
- If you don't see the meetings as recurring events on your calendar, ask Xavier to send you the invitation.
- After the sprint has been planned and started, it's time to code! If it's your first sprint, your mentor should have assigned you a task, in addition to the onboarding task.
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.
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.
The steps involved in that planning are described in the sprint planning checklist template, as well as the follow-up tasks to be done during the sprint itself.
Our bot creates a dedicated checklist for each member, every sprint, in the workspace which corresponds to their cell. The checklist is to be completed by all team members during the sprint, according to the timelines described there.
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.
The sprint planning manager creates the sprint estimation session in Jira. An email with a link is sent out when the session opens. For each task:
- 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
- Assign points as described in the process section
- Use the "estimate comments" box to qualify estimates
?if you have no idea how many points
- A little green
(/)will appear next to your picture up top when you are done
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.
The following process applies when someone wants to add a ticket to the sprint after the Thursday EOD 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 video update¶
The video updates 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 completes the video format as necessary. The updates are posted in a dedicated "Sprint updates" forum thread for the cell, reusing it between sprints.
- 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 use 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 Async planning meeting videos folder, and use an iframe to display the video inline in your post:
<iframe src="https://drive.google.com/file/d/[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
forum.opencraft.comto 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 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
With the move to asynchronous planning meetings, we don't get to interact with each other in videocalls regularly anymore! 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 meeting).
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.
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 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.
Business Cell Sprint Planning Meeting Agenda¶
The sprint meetings have the following agenda:
- 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.
- Close the current sprint, setting all still open tickets to move to the next sprint.
- 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.
- After confirmation on all items above, start the next sprint.
- 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.