Commit b80c9071 authored by J. Victor Martins's avatar J. Victor Martins
Browse files

Remove references to "Sprint Planning Meeting"

parent 2eff40f8
......@@ -44,7 +44,7 @@ In all cases, time is logged on tickets from the cell owning a specific epic. To
To allow proper planning and to allow assignees to follow their tasks from a single board during the sprint, tasks from cell A show on cell B's sprint board when some of the reviewers are from cell B. To allow to clearly differentiate them visually, they are shown in purple on the boards, and a “Hide not in cell” filter is available.
Note that since sprint planning meetings are done per cell, cross-cell assignation of reviewers should be discussed and decided ahead of the sprint meeting as much as possible.
Note that since [sprint planning](/processes/sprints/#sprint-planning-process) is done per cell, cross-cell assignation of reviewers should be discussed and decided ahead of the beginning of the next sprint as much as possible.
## Remote Work
......@@ -54,7 +54,7 @@ For many companies, 'remote work' means that you get to work remotely some days
OpenCraft is truly remote. Aside a few off-hours meetings for timezone reasons, everyone is free to decide to work, and from where. The important part is to be able to get the work done and communicate frequently -- which requires having a good Internet connection and enough hours.
OpenCraft endeavours to make as many of our processes as asynchronous as possible so that no one has to work outside their preferred hours. Until 2020, we planned our sprints in a real-time meeting. Everyone would have to hop on for sprint planning even if that meant getting up at 3 in the morning. Today, our sprint planning process is [asynchronous](https://handbook.opencraft.com/en/latest/processes/#planning), and while you may occasionally need to meet with a teammate or client outside your preferred time window, it's not the norm.
OpenCraft endeavours to make as many of our processes as asynchronous as possible so that no one has to work outside their preferred hours. Our sprint planning process is [asynchronous](/processes/sprints/#sprint-planning-process)), and while you may occasionally need to meet with a teammate or client outside your preferred time window, it's not the norm.
One exception to our remote work policies is the Open edX conference. The conference happens each year, and if a talk you submit is selected, you'll be flown in to the conference to meet with the team and community members in person. Another exception is the occasional company retreat. However, you will never need to move in somewhere 'local.'
......
......@@ -5,7 +5,7 @@ Once a newcomer has signed their contract, the CEO creates an [onboarding checkl
Once the newcomer has access to the tools and joined the team, the onboarding and trial period starts.
Since newcomers may start at any time during the sprint, this process overlays the [sprint process](sprints.md).
Newcomers are expected to participate in sprint planning meetings, commit to tasks for the upcoming sprint, and practice
Newcomers are expected to participate in sprint planning process, commit to tasks for the upcoming sprint, and practice
time management using the sprint planning tools and by updating the Remaining Time estimate fields on their tasks.
As with all things at OpenCraft, this process is continually being reviewed and improved, so please provide any
......@@ -17,7 +17,7 @@ suggestions or feedback on your onboarding task.
| **Week 0** | Work on your onboarding task, which involves reading documentation, completing the onboarding course, and setting up an Open edX devstack.<br/>You'll also have a newcomer-friendly task assigned to work on in the first week, after finishing your onboarding.<br/>Attend the 121 meeting scheduled by the reviewer of your onboarding task to say hello and discuss your progress.<br/>If your devstack gives you trouble, be sure to ask your reviewer or on the Mattermost #devstack channel for help, and/or arrange a synchronous meeting to work through any issues.|
| **Week 1** | You've likely finished the onboarding course and your devstack setup, and are ready to work on a [newcomer-friendly](../task_workflows.md#newcomer-friendly-tasks) or other small task.<br/>Reach out to your mentor or the sprint firefighter to help find tasks and a reviewer from the core team to help you.<br/>To avoid spillover, we recommend against pulling new tasks into the current sprint in the first instance -- the review cycles can often take more time than expected. So instead, especially if a new sprint is starting soon, commit to a task in the next sprint, and work ahead.|
| **Week 2** | At the end of this week, your mentor and 2 other core team members will complete a [screening review](#evaluation-criteria) of your work so far.<br/>This review exists to provide early feedback, and to identify extreme issues like a failure to communicate within 48h of pings on tickets and Mattermost, or cases where excessive time has been logged to tasks without sufficient explanation or outcomes. In this case, we would give notice that the trial period will end. But if you're communicating on your tasks and making progress, then your trial will continue as scheduled. Your mentor will pass on any feedback -- positive and negative -- from this review.|
| **Week 3** | By the end of this week, you should have [completed some tasks](../task_workflows.md#done), with [story points](../task_workflows.md#general-tasks) totalling around 8-12 points. If you haven't, bring this up as soon as possible with your mentor.<br/>If you've had spillover, consider what went wrong during these tasks and talk about it with your mentor.<br/>Take care not to overcommit during the next sprints to get this under control. Time management is one of the hardest parts, so after each sprint ends, take care to ensure that the Sprint Commitments spreadsheet (linked from each cell's weekly sprint meeting) is accurate, and your spillover is improving as you progress through the trial period.|
| **Week 3** | By the end of this week, you should have [completed some tasks](../task_workflows.md#done), with [story points](../task_workflows.md#general-tasks) totalling around 8-12 points. If you haven't, bring this up as soon as possible with your mentor.<br/>If you've had spillover, consider what went wrong during these tasks and talk about it with your mentor.<br/>Take care not to overcommit during the next sprints to get this under control. Time management is one of the hardest parts, so after each sprint ends, take care to ensure that the Spillover Spreadsheet is accurate, and your spillover is improving as you progress through the trial period.|
| **Week 4** | By this time, depending on when you started, you've completed 2-3 sprints, so it's time to ensure that you're completing a breadth of tasks to showcase your skills.<br/>Have you taken on increasingly difficult tasks?<br/>Have you submitted a PR to the Open edX platform?<br/>Have you launched appservers or contributed to Ocim?<br/>Have you completed any devops tasks?<br/>Have you been the primary reviewer on some tasks?<br/>If not, try to find tasks for the next sprints which would fill these gaps, and discuss any cell-specific expectations with your mentor.|
| **Week 7** | This week will be your developer review.<br/>All the core team members in your cell (plus one developer from each other cell) will review your tasks, PRs, and communications, and vote on whether to accept you into the core team, extend your trial period, or end your trial.<br/>All reviewers have to agree to confirm a new core member. We each do our own evaluation independently, and then discuss if there's a difference of opinion.|
| **Week 8** | This marks the end of your initial trial period -- Xavier will meet with you to discuss the results of the developer review.<br/>If you're joining the core team now, congratulations! There will be a small core team onboarding task to complete in your next sprint, and you can continue logging "onboarding" time to your onboarding ticket for a while.<br/>If your trial period has been extended, that's great too! Xavier will provide specific details on the improvements required during the extension, and it's really important to focus on these areas during your extension.|
......@@ -32,7 +32,6 @@ The screening and developer reviews will be evaluated on the following criteria:
Team members must demonstrate development and devops abilities on basic and complex tasks.
* Time management and spillovers.<br/>
Newcomers must have at least half of their sprints clean during their initial trial (2/4), or two thirds of their sprints clean for extended trials (rounded down, eg. 5/8). Confirmed core team members are expected to have at least 75% of their sprints clean.
Sprint status is documented on the Sprint Commitments spreadsheet (linked from each cell's weekly sprint meeting).
* Communication.<br/>
See [Roles: Communication](../roles.md#communication) for the expected response times, and the additional
expectations for [Newcomers](../roles.md#newcomer).
......
This diff is collapsed.
......@@ -96,8 +96,6 @@ The general expectations for anyone working at OpenCraft:
and timezone overlap if I didn't have knowledge about it before. I will use the
[contact sheet](https://docs.google.com/spreadsheets/d/107dR9H1vWjLpJlXPuBaFJIFaEPEmaSh50xLow_aEGVw/edit)
where necessary.
* I will join the weekly sprint meeting of my cell on Mondays, unless I have scheduled that day
off in advance.
### Sprint tasks
......@@ -129,9 +127,10 @@ The general expectations for anyone working at OpenCraft:
1. Which days will you work on which task?
1. When do individual parts need to be completed to be on time?
* It's also important to keep some margin on the sprint, in case something doesn't go as expected.
* I will get my tasks to at least **External Review** (or "Deployed & Delivered" if no external review is required) by
**one hour before the sprint planning meeting for the next sprint**. As this is also dependent on
the internal reviewer, I'll make sure she/he will be available around the time I finish.
* I will get my tasks to at least **External Review** (or "Deployed & Delivered"
if no external review is required) by **one hour before the next sprint**. As
this is also dependent on the internal reviewer, I'll make sure she/he will be
available around the time I finish.
* If it is looking like I will have trouble meeting one of these deadlines,
I will inform the [sprint firefighters](#firefighter) (and [epic owner](#epic-owner)) as early as possible,
so they can get me additional help, start planning for contingencies,
......@@ -171,7 +170,7 @@ consider swapping/dropping it.
Once someone takes up a role in a call there generally no need to reassign it unless someone leaves
OpenCraft. While an appointment to a role is generally permanent, no one should feel stuck in a
role if they are no longer comfortable in it. As such it is desirable to openly discuss with other
members of the cell on the forum, and perhaps in the sprint meeting when such a situation arises.
members of the cell on the forum.
It is the responsibility of the current person with a role to find a replacement in their cell and
help their replacement during a transition period while they are still getting comfortable with
......@@ -189,12 +188,13 @@ There are three types of members at OpenCraft:
* *Short-term members* (temporary contractors), who have been hired for a specific task, scope
or period of time. They are the most external members of the team.
* *[Newcomers](#newcomer) on probation* (2 months, renewable).
* *Core team member* - the new recruits who have been confirmed become core team members. They differ
from the other types of members in that they tend to have more team-based responsibilities.
For example, core team members are on a
[weekly rotation schedule](https://docs.google.com/spreadsheets/d/1ix68BsU2hJ2ikexXWeBcqFysfoF4l7IKRghIDQgyfPs/edit#gid=447257869)
where they often have to take on some additional roles, including Sprint Firefighter, being on
Discovery Duty, and occasionally leading our weekly sprint kick-off meeting.
* *Core team member* - the new recruits who have been confirmed become core
team members. They differ from the other types of members in that they tend
to have more team-based responsibilities. For example, core team members are
on a [weekly rotation
schedule](https://docs.google.com/spreadsheets/d/1ix68BsU2hJ2ikexXWeBcqFysfoF4l7IKRghIDQgyfPs/edit#gid=447257869)
where they often have to take on some additional roles, including Sprint
Firefighter and being on Discovery Duty.
However, in all other regards, all types of developers are put to the same expectations -- no
politics or special treatment between short-term developers, newcomers, and core team members.
......@@ -722,9 +722,8 @@ there, let the [Sprint manager for your cell](cells.md) know.
### Firefighter
There are two firefighters per cell for each sprint and they are designated as Firefighter 1 and 2.
Besides minor differences who leads which sprint meeting, these roles have exactly the same
responsibilities.
There are two firefighters per cell for each sprint and they are designated as
Firefighter 1 and 2. These two roles have exactly the same responsibilities.
As a **sprint firefighter**:
......@@ -785,19 +784,18 @@ As a **sprint firefighter**:
The severity level mentioned in a vulnerability report may not always match our own assessment (`critical issues` in a disabled feature may not be `critical`). Hence the processes around categorization of the security vulnerabilities and the assessment of their severity levels need to be expanded and improved over time.
* Work on additional tasks from the backlog if additional time is available
* Well before the sprint planning meeting at the start of a new sprint (every
second Monday), I will remind the epic owners to get every ticket in the upcoming sprint
"green" (has an assignee, reviewer, and points) by pinging people as needed,
and I will help make sure all tickets are green before the start of the sprint planning meeting.
If my timezone makes this challenging, I will coordinate with Firefighter 2 to finish up on Monday.
The time spent getting a ticket to green will be logged on the ticket.
* If I am Firefighter 1, I will lead the sprint planning meeting at the start of
the sprint. If I am Firefighter 2, I will take notes during this meeting. For the
mid-sprint meeting these roles are reversed, Firefighter 2 will lead the meeting
and Firefighter 1 will take notes.
* On Friday or Monday well before the mid-sprint meeting, I will do a sprint checkin
on all "backlog" and "In progress" tickets (this means to post a comment
on each ticket to ask how the assignee is doing and if they need help,
* Well before the end of the current sprint, at the start of a new sprint (every
second Monday), I will remind the epic owners to get every ticket in the
upcoming sprint "green" (has an assignee, reviewer, and points) by pinging
people as needed, and I will help make sure all tickets are green before the
start of the sprint. If my timezone makes this challenging, I will coordinate
with Firefighter 2 to finish up on Monday. The time spent getting a ticket to
green will be logged on the ticket.
* On Friday or Monday well before the mid-sprint update, I will do a sprint
checkin on all "backlog" and "In progress" tickets (this means to post a
comment on each ticket to ask how the assignee is doing and if they need help,
and/or asking them to update the status of the ticket if it is not clear).
### Community Relations
......@@ -1148,7 +1146,7 @@ There are a few exceptions:
if no backup person was planned.)
We have a few clients with monthly development budgets. For those clients, the assigned client owner
is also responsible for reviewing the monthly budget before and during each sprint planning meeting,
is also responsible for reviewing the monthly budget before and during each sprint,
to ensure that we are not going too far above or below the budget. They should refer to the
[Sprints](https://sprints.opencraft.com)
which can monitor and project the status of each budget as of the end of the upcoming sprint.
......
......@@ -365,10 +365,10 @@ you spend doing your own company's accounting or taxes for example).
#### Look for recurring tickets
Some tickets are meant to be used to log recurring tasks such as the time
spent in sprint plannings meetings. When in doubt and before asking
for a specific ticket, go to the `Recurring` column of the sprint
dashboard and look for a ticket that may fit what you are doing.
Some tickets are meant to be used to log recurring tasks such as the time spent
in sprint planning. When in doubt and before asking for a specific ticket, go to
the `Recurring` column of the sprint dashboard and look for a ticket that may
fit what you are doing.
#### Start to track your time immediately, before knowing where to assign it
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment