6.39 KB
Newer Older
# Process for sprints

3 4 5 6 7 8 9
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. |
11 12 13 14 15
| 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.<br> **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. |
18 19 20 21 22 23 24 25 26

## Detailed version

### 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.
27 28
* 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
29 30 31 32 33 34
  summary or sentence of where you're at with the task is useful to your reviewer.

### Developer Team

* 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.
39 40 41
    * 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
Piotr Surowiec's avatar
Piotr Surowiec committed
      [task workflows]( for more detail on story points for different types
44 45 46 47
       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.
48 49
      Note that during the asynchronous refinement sessions, any comments/questions
      posted in the estimation session will be lost once the refinement session ends,
50 51 52 53 54 55 56 57 58 59 60
      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]
62 63 64
      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
66 67
  for the upcoming sprint (please see the [sprint planning agenda](
  for details of this meeting).
    * The meeting link is in the calendar invite.
69 70
    * 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
72 73 74 75 76
  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 <em>My Issues</em>, <em>My code reviews</em>, and your
78 79 80
  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.
81 82 83
* 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
84 85 86
  reactive too).
* Use the Tempo timekeeping system built into our JIRA board for tracking the time you spend on
  each task.
87 88

[Sprints app]: