Cantilever plans its work in two-week cycles, called “Sprints.” This methodology is derived from the classic agile SCRUM methodology, which all Core Team Members should be comfortable working in. Each sprint represents all the work that Cantilever is committed to delivering over that two-week period. Sprints start on a Thursday and end on a Wednesday.
Completing each sprint is a collective goal. Core Team Members are responsible not only to completing the sprint work they are related to, but also to help anyone else who may be behind on any work within the sprint, so the company as a whole can meet this goal. Contributors are primarily responsible for their own tasks, but should feel free to look for other tasks on which they may want to offer their help as well.
The Sprint Owner
Sprints are facilitated by a Sprint Owner who is in charge of enforcing our processes and helping to shepherd the sprint to completion. The current Sprint Owner is @Ty Fujimura but in the past we have rotated sprint-by-sprint and we may go back to that at some point.
Sprint Owner Duties
- As often as possible (at least three times per week), review the big board for the current and future sprint. Make sure that tasks are in the right places, have appropriate statuses, are actionable and accurate, etc.
- Send regular updates on the sprint status via the Asana status updates…
- After a new sprint starts
- At the mid-point of a sprint
- A few days before the end of the sprint (Rally the team to finish strong)
- Whenever something is not going correctly (ex. tasks with no assignee, tasks not being worked on late in the sprint, staff behind on deadlines, etc.), DM the appropriate staff to push for a resolution.
- Conduct the Weekly meetings.
- When the sprint changes (Wednesday EOD/Thursday Morning)…
📈 The Big Board
We track our sprints using a shared Asana project called the “Big Board”:
The Big Board contains all the shared, common fields we use on our
PMs should add work to the Big Board as soon as it is being realistically planned for completion, even if it might not be worked on for a while. Tasks can live in the Big Board whether or not they are in a Sprint.
What is Included
Some tasks should go in the Big Board, while others should not. If the task has a clear external deliverable that we use our production workflow to complete, it should go into the sprint.
- ✅ Most design, development, and content work ≥ 1 hour in duration
- ✅ All technical consulting or strategy work with a clear external deliverable
- 🚫 Strategy work with no clear external deliverable. For example, assisting with task clarification should not be in the sprint.
- 🚫 Hotfixes
- 🚫 Most Quick tasks < 1 hour
- 🚫 Approvals
- 🚫 Milestones
- 🚫 Project management work
- 🚫 Most QA work – this should be done as sub-tasks on the task it self
Task Size
Generally tasks on the big board should be less than 8 hours. If a task is larger than 8 hours, it should generally be broken up into smaller tasks that are clearer and more easily reviewable by a single approver.
Statuses
The Big Board contains sections that match our task
🏃🏾♀️Sprint Workflow
Pre-Sprint (>1 week to sprint start)
Project managers and strategists should continually work with their clients to gather and clarify work to be done. They should be putting this work into the Big Board as soon as possible. If we commit to getting the work done by a specific date, the work should bear that date and should be put into the appropriate sprint, even if it’s a long time from now.
Work going into the Big Board will automatically get the “Inbox” status. The Sprint Owner should review it for suitability on the Big Board. If suitable, the Sprint Owner should move it to Task Definition.
One week before a sprint begins, the team will meet and review the current work planned for that sprint and compare it to the planned capacity of the team.
→ If there is too much work in the sprint, we need to move lower-priority work back.
→ If there is too little work in the sprint, we need to find other future work and pull it up, or work to get more into the big board.
At this stage most of the tasks will be rough and unclarified and will typically be unassigned.
Sprint Prep (<1 week to sprint start)
As the sprint approaches, PMs are responsible for getting the tasks clarified and ready for the sprint by the Sprint meeting on Wednesdays. As they get tasks clarified, they may ask potential assignees if they would like to take on certain work. Once work is clarified and assigned, it can move to “Ready”.
To be Ready a task must have:
- The Importance, Hours Estimate, Client Code, and Task Type fields populated.
- An assignee who either volunteered for the task or explicitly accepted responsibility for it
- A clear and detailed description according to our Standard Cantilever Task Fields
- A due date that is within the sprint. If a task does not have a “natural” due date but is in the sprint, it should be given a due date of, at the latest, the Tuesday before the sprint ends.
By the time of the sprint kickoff meeting, all planned work for that sprint should be in the Big Board and associated with that sprint.
Designers & Devs can preview the upcoming sprint and proactively claim tasks they want to take, at any time.
Sprint Kickoff
During the meeting, any still-unassigned work should be assigned collaboratively amongst the team according to remaining capacity.
At this point there may be some lingering work from the prior sprint that did not get done. If it’s impossible for us to complete that work on time, it must be re-scoped and re-submitted to the board as a new task for the remaining work, including a summary of prior context.
By this milestone, all work for the sprint should be in “Ready” and should be clarified and assigned.
During the Sprint
Task assignees should work on their highest priority items, as implied by the due dates and the Importance field. As tasks are worked on, it’s the assignee’s job to move them through the sections from “Ready” to “In Progress” to “In Review” to “Ready to Deliver”. This will typically involve getting some kind of approval. The required approvals should be noted on the task by the PM.
No tasks in the sprint should ever be overdue. If they are overdue, they should be renegotiated immediately between the PM and Sprint Owner.
Closing the Sprint
As the end of the sprint approaches, the Sprint Owner should be closely tracking any remaining items to ensure we have a solid plan for completing them. The team should be eagerly hopping onto items which may be behind, even if they were not originally planning to work on that task.
During the sprint closing meeting, the Sprint Owner will provide a recap of the company’s results over the last sprint and we should celebrate wins and highlight opportunities to improve.
Sprint Workflow RACI
Process | Responsible | Accountable | Consulted | Informed |
Putting tasks into the Big Board | PMs | Strategists | ||
Clarifying tasks | PMs | Strategists | Devs & Designers | Sprint Owner |
Getting tasks assigned | Devs/Designers | Sprint Owner | PMs | Strategists |
Completing tasks (including approvals), moving tasks through the board | Devs/Designers | PMs | Strategists | Sprint Owner, Clients |
Maintaining Big Board workflow & cleanliness, approving work to enter/leave the board | Sprint Owner | Sprint Owner | PMs & Strategists | Designers/Devs |
Ensuring the sprint is completed in full | Full Team | Sprint Owner |
📆 Weekly Meetings
The weekly meeting occurs on Wednesdays and is mandatory for all Cantilever Core Team members and PM Contributors. The Sprint Owner is the host of the weekly meeting.
Sprint Turnover Weeks
- Review the current sprint together and collectively discuss any work that is not done. Ensure there is a plan in place to get that work done, or to redefine it so that it can be completed. Some parts of some tasks may need to be re-scoped as new work for the next sprint.
- Review the Dashboard from the current sprint and discuss the stats
- Conduct a sprint retrospective conversation. Encourage the team to shout-out teammates who did a great job during the sprint. Discuss any challenges that occurred during the sprint and identify patterns that we may need to address. Decide on who is responsible for addressing those challenges.
- Review the next sprint and ensure that…
- Only tasks that are complete and assigned are in “Ready”. They should have all required fields, due dates, etc per the Workflow defined above.
- There are no more tasks in “Task Definition”, or there is a clear plan for getting them ready by the time the sprint begins on Thursday
- Check the capacity of each team member and make sure they have a realistic amount of work assigned to them given their personal schedules
- If we have too much work in the sprint for the Core Team, decide on Contributors to ask to take on specific items.
Mid-Sprint Weeks
- Review the status of the current sprint and make sure that each task is still in good shape and on track for agreed-upon deadlines
- Review the Dashboard and discuss the stats
- Preview the upcoming sprint
- Review stuff that has already been added to it, discuss plans for finalizing that work and potential assignees
- Review Unscheduled items and see if any should go into the sprint
- Proactively discuss PTO plans for the upcoming sprint and make sure everyone is aware of capacity for each person
- Collectively discuss ideas for work we could suggest to clients that could go into the sprint (strategy work, updates/upgrades, etc)