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 SprintCraft to review cell member's time allocation and ensure everyone has enough work and is 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 their cell's SprintCraft board 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.
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>.
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.
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.
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.
?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.
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.
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.
- 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="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 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.
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).
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. At the beginning of the sprint, a synchronous retrospective meeting is automatically scheduled for the day after the sprint ends.
All team members for whom the meeting falls in their regular working hours are encouraged (but not required) to join the sprint retrospective meeting. One team member leads the meeting-- conventionally, this is the first week Sprint Firefighter, or the Sprint Manager if the sprint firefighter isn't available. However, any team member can take the lead if they like, especially if neither of the people with those roles are in the meeting.
- Each team member is asked how they felt about the sprint.
- The team discusses the items in the Sprint Retrospective document.
- Any other problems, venting, or questions from the last sprint are brought up for discussion.
After the meeting concludes, the meeting lead writes a summary of the issues in the Sprint Retrospective thread on the forum, and posts the meeting recording. If necessary, they (or the team members affected) schedule follow-up tasks to address issues, or ping the Developer Advocate for consult.
The sprint retrospective exists to help address problems discovered in the previous sprint. To make sure that members still have an opportunity to have fun face-to-face interactions with their team, we also have the social chats. They are more informal and optional. Team members from any cell can attend any social chat.
The social chats, like the retrospectives, are automatically scheduled. To keep things interesting, the firefighter for the first week (the organizer) picks a topic or activity and posts that to the social chat forum thread. Once the meeting begins, team members are not required to stick to the topic, but it helps to get the conversation flowing.
If the first week firefighter won't be attending the social chat, they should still pick a topic, but should also indicate they won't be able to attend, so that someone who IS able to attend can offer an alternative suggestion if they prefer. This person can swap in to become the organizer.
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 updates the automatically created calendar event on the cell's calendar. It should be verified to include:
- The description of the topic/activity 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.
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.
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.