How Casper’s Tech team plans a full quarter of software releases
I remember my first quarterly planning like it was yesterday. I was leading a small team of software engineers at Optimizely. I flew to the San Francisco headquarters and jumped right into the deep end without ever having done much planning in my career. The process was so overwhelming that I was visibly shaking and my voice was cracking when I presented my quarterly plan to the whole company. The experience changed me. Ever since I have been a planner to my core, bringing it to every company where I’ve worked.
Success with quarterly planning has varied at each company. It worked well at Optimizely. It didn’t work all that well for the Hillary ’16 presidential campaign. It’s working very well at Casper. At each place we’ve made changes to the process to help it fit into the uniqueness of the company. After six years of evolution I’m happy to share Casper’s quarterly planning process.
Before getting into the specifics though, I think it’s important to know a little about Casper first. As I hinted at earlier, quarterly planning isn’t cookie-cutter and it may not work well as presented at your company.
Casper is a sleep company. Our mattresses are our flagship products, but we make an array of sleep products. Our business is omnichannel. We sell our products through e-commerce, Casper owned retail stores, and retail partners like Target and Amazon. Our approximately 80 person Tech team develops the software behind our global e-commerce platform, the POS device in our retail stores, a multi-content logistics and fulfillment network, data warehouse, CRM platform, data and integrations for retail partners and our ERP, and technical operations. Our Tech team is ever growing, mostly centered in NYC, with team members in the San Francisco, Los Angeles, and Berlin Casper offices. We have small “pods” of 3–7 people focused on one area like order fulfillment, data engineering, or retail as examples.
Now that you have some context, let’s dig in!
The best place to start is by looking at quarterly planning on a calendar.
The first thing you’ll probably notice is that we start planning early for the upcoming quarter! In my experience, starting earlier is one of the best things you can do to ensure success later in the calendar. Each section of this post will cover the gray items on this calendar.
Leadership alignment
Alignment among the leaders of a company is a critical part of the process for many reasons. Engineers needs to know that company leaders agree that the boulder projects and OKRs are the right big bets. Also, in an ideal world, we wouldn’t make huge changes to the roadmap after we’re done planning it because a company leader wasn’t in the loop.
There isn’t a lot of structure to our leadership alignment process. A lot of this happens in weekly Tech leadership meetings and one-off meetings with the CEO and other C level leaders. In some cases we distribute a list of projects over email. The process is pretty flexible for the work style of each leader. We are typically engaged with Casper leadership throughout the process to ensure that everyone is up to date with new developments.
OKRs
Before sitting down to plan a quarter of work it’s important to know what your goals are. We use the objective and key results (OKR) structure popularized by Google and other big technology companies. At Casper, each Tech pod creates their own OKRs. We don’t put a strict requirement on the number of OKRs, but we suggest at least a few OKRs supported by a handful of measures.
As an example, the pod that manages the frontend of the website might focus on three objectives in the upcoming quarter:
- Decrease page load times
- Increase SEO ranking
- Refresh the branding of the website
The measures for the first objective might look like this:
- Reduce start render time to 2 seconds
- Reduce time to first byte time to 50ms
- Reduce time to interactive time to 5 seconds
The pod will use these OKRs as a guiding light during roadmap planning. It’s important that the leadership and pod get as close consensus as we can on OKRs before going into roadmap planning.
Pods are asked to keep the data on these OKRs in a spreadsheet or dashboard. They present progress on their OKRs a few times throughout the quarter. Each Tech all-hands meeting is an opportunity for pods to present progress on their OKRs. Additionally, at the beginning of the next quarterly planning, each pod presents their end result. These presentations help reinforce ownership and accountability on the OKRs. We’ve recently taken this a step further and asked individual software engineers to own some of the pod OKRs as their quarterly performance goal. We then take progress on the OKR into account in performance evaluations.
In addition to OKRs we have a concept of key performance indicators (KPIs) that we use to measure more evergreen metrics. These are metrics that signal the overall health of the application like error rates, response times, etc. These are typically tracked in a monitoring tool like DataDog. These KPIs are largely owned by the Tech Lead of a pod.
Initiative capture and prioritization
A big part of our quarterly planning process is understanding what the company needs from the Tech team in the next quarter. We call this initiative capture and the process is lead by our Digital Product Managers. We have a master Google spreadsheet with a sheet in it for each Tech pod. Then we ask every stakeholder to input the projects they’d like Tech to work on. The spreadsheet is always epically large with hundreds of rows.
It takes a lot of work to get through initiative capture list. Product Managers work closely with their stakeholders to define the projects, gather requirements, and determine use cases. The depth of information we collect and document depends on the likelihood the project will get prioritized and the size of the project. High priority, large projects will get the most attention. For these we will go through a full product spec written by a Product Manager. These documents outline the project, the business case, its goals, the requirements, and use cases. Then we’ll create a companion document on the engineering side called a technical design. This document is around 14 pages of detail on the technical execution and design of the project. Think architecture, integration, data models, security, scaling, etc.
We try our very best to have both the Product Spec and Technical Designs for every big project done before we start planning roadmaps. It’s very hard for engineers to plan out their quarter of work if they are unclear about what they are building. Without these documents the estimates in the roadmap will not be very informed and are less accurate.
Roadmap
Roadmap development is where the rubber hits the road and it’s my favorite part of quarterly planning. Usually we book an offsite location for two days and fly all of our team members and contractors into NYC for the week. We do this planning offsite because it should feel different than normal work. We don’t want engineers solving tickets, distracted by stakeholders, or otherwise caught up in their normal day to day at the office. We want them to be solely focused on planning the upcoming quarter.
It’s expected that every pod produces a full roadmap for the quarter, complete with tasks for every engineer for every sprint. They are not meant to be a work of art etches into stone that can never change. They’re meant to just be a roadmap that we try our best to execute against. We may need to react to new information in the quarter and adjust the plan and that’s OK. To create these board we like to step away from our computers and do this the good old fashion way with stickies, markers, whiteboards, and posterboard.
Before creating a board, each pod outlines their quarter based off of a planning board template. They put the sprints in the quarter like a calendar (blue boxes). Each engineer has a swimlane in every sprint (yellow boxes). Important dates (purple boxes) like product launches, press releases, and planned vacation (teal boxes) for engineers are clearly marked. Dependencies on other Tech pods (green boxes on top of red) are explicitly called out. Once the quarter has its structure, the team begins to fill in the roadmap.
The fidelity of the roadmaps vary pod by pod. Some pods have enough information and precision to assign every task to an engineer and have defined tasks in every sprint. For many reasons other pods may not be able to accomplish that level of detail. Their boards may have unassigned tasks in sprints or leave sprints somewhat empty because of uncertainty. We try our best to prevent this, but it happens.
In the quarterly roadmap, the tasks in each sprint are defined broadly. Each sprint usually has 1–3 stickies per engineer like “Refactor hero module” and not multiple, well-defined tasks that you’d see in a Jira sprint. The farther out in the quarter the more the accuracy goes down. We expect the first two sprints of the roadmap to have a high accuracy, but that accuracy expectation lessons further out in the roadmap. The last sprint can sometimes feel like a guessing game and that’s OK.
I always suggest teams to immediately convert their quarterly roadmap into Jira after it’s complete. Once quarterly planning is done, things move quickly and keeping state on an analog planning board with stickies is difficult.
Capacity management
Capacity management aims to solve two problems: Pods overcommitting themselves, thus working too many hours and missing deadlines, or pods under committing themselves, thus delivering underwhelming roadmaps.
We have a few guidelines for pods to gauge their capacity to take on work. The first is to only allocate 80% of the resources per quarter. The remaining 20% can then be used to work on unplanned items which are inevitable. This is a guideline, however. Some pods may need to do 90/10 because of a big launch. Some pods may do 70/30 because they are more service oriented. How exactly do you plan for 80/20 two months in advance? It’s not a science and you may have to use your gut. I’ve seen some especially efficient pods point out all their tasks for the quarter and adjust 80/20 based on those points. It is possible! If a pod isn’t that efficient, using your best judgement is OK. Also, it may be easier to keep one person unallocated for a week in a two week sprint rather than fussing with the minutia of keeping all 5 engineers at 80/20. Keeping the pod’s overall capacity at 80/20 instead of each engineer is a good strategy.
Pods also need to plan for vacation. On many occasions I’ve seen beautifully planned boards with no vacation time factored in. It hurts to do it, but I’ll ask the pod to take another stab at the plan, this time with at least 5 days of vacation days for every engineer. 5 days is a guideline. If someone has 10 days of vacation coming in the quarter, that’s great, the time just needs to be earmarked in the plan. Engineers are encouraged to think about what dates they want off before the quarter starts. This serves as a nice reminder to actually take vacation, which we all need to do, and helps planning. If an engineer doesn’t have any vacation planned because, say, they just took a month off, I still recommend planning for 5 days because of illnesses.
Another often overlooked item is new hires. When a new hire is scheduled to start in the quarter, the pod gains addition capacity. This is an awesome opportunity to plan out the new hire’s work before they start. This has the added benefit of making the new hire feel welcome and needed. They’ll have a list of projects to complete so that they can immediately provide value to the company. In addition to new hires, it’s important to include end dates for team members leaving the pod and decrement the capacity.
Identification of dependencies
An unidentified dependency can cause double damage to a Tech team. The longer the dependency goes unidentified the worse the damage can be. A common example I see of this is a pod, let’s call it Payments, not notifying the infrastructure pod, let’s call it Tech Ops, that they intend to launch a new service. The Payments pod gets 80% of the code done for the application and then notifies Tech Ops mid-quarter that they have a new application to deploy. Tech Ops is caught by surprise and a conversation starts on whose sprint needs to change. Should Payments have to delay their launch because they notified Tech Ops too late? Is delaying the launch even an option? If not, the Tech Ops sprint falls behind plan. At best one sprint gets delayed, at worst, both sprints.
The expectation of quarterly planning is not that all dependencies throughout the entire quarter are identified. Instead the expectation is that we manage the dependencies we know about during planning. New dependencies will come up as the quarter goes on because of new information, but this is OK. An agile method of working can help deal with this.
Dependency management is a two way street, by the way. In the example above, both pods missed the opportunity to properly manage the dependency. Yes, the Payments pod should have proactively told Tech Ops about the application launch. It is also true that Tech Ops should have looked at the Payments quarterly planning board to see that Payments wants to launch a new service.
We mark dependencies on planning boards with a bright sticky note on top of the project that has the dependency. There should be two sticky notes for each dependency. To continue with the example above, there should be a dependency sticky on the Payments board and a sticky on the Tech Ops board. Here’s an example:
Our quarterly planning offsites mark the transition between quarters. This is one way we break up the work between quarters and give the teams a breather. Instead of the whole year feeling like a death march to ship code, we take a break in-between quarters.
At the end of the first day of quarterly planning we host a company paid happy hour at the offsite location. Then after the end of the second day we host a bigger team outing at a bar. In the past we’ve also tacked on a 3 day hackathon after quarterly planning so there is a full week of transition between quarters.
We are always making tweaks to the format of the offsite. Above is a timeline from one of our offsites. We bring in breakfast and lunch every day. We have working sessions for each pod to go heads down on their roadmap. The “dependency rotation” is for everyone to go around and look at each other’s boards. This helps identify unknown dependencies, sync timelines, and share knowledge.
Our pods have become much more efficient at quarterly planning over the past six times we’ve done it. What we’re seeing now is that most pods finish the majority of their planning in the first day and have too much downtime the second day. We’ve also gotten feedback that the presentation part is too long and the presentations are too details. We’re currently brainstorming solutions to both of these.
Take a deep breath. Now let it all out. Phew! At this point our teams have gone through a lot of work to develop a 3 month roadmap. And it would be a shame to stop there. The quarterly planning process produces a lot of great information and we share it with the whole company. There’s one last step here and that is to abstract a lot of the information into a digestible format. The audience for these share outs are technical and non-technical people outside of the pod. It also ranges from executive to entry level employee.
We put a lot of information in the share out slides because you never know who is going to look at the slide. It could be a new employee hired a month from now! Here’s what’s included in share outs:
- Pod name and mission statement
- Member of the pods with photos (important for people to know who to direct questions to)
- OKRs and KPIs
- High level quarter roadmap
- Deferred work (the big projects we said no to for the quarter)
We start first with a share out to senior leaders at Casper. (the “C suite”) Occasionally there are some tweaks and adjustments from this share out, but for the most part the roadmaps remain intact. After that we schedule a 60 minute one-off meeting with each department at Casper (e.g. Marketing) and debrief where their priorities landed in the quarter. And lastly we host a lunch-and-learn for anyone in the company to attend where each pod gives a lightning talk for their roadmap.
In addition to the in-person share-outs, the planning documents are all archived in Confluence and Google Drive so that they are easily accessible if someone needs to reference them. We don’t have a department wide method/policy for keeping the roadmaps up to date as information changes. Some pods will update their roadmaps when things change and some don’t.
