So I thought I’d give everyone a peek at how we run sprint planning at CloudHealth Technologies. I won’t claim it is a perfect process by any means, but like any good process, it is constantly evolving to meet the needs of our business, customers, product and team.
Aspirational Goals
In designing our sprint planning process, we had the following goals:
- Customer-driven - Successful companies build products that matter. The voice of the customer should be loud and clear in sprint planning.
- Transparency - The group is always smarter than the individual. But you can’t harness the power of the collective if you don’t enable an open / honest flow of information.
- Empowerment - Good things happen when you hire great people, provide them the right information, and then get out of their way.
- Meritocracy - The best idea to drive customer success should win. Period.
- Agility over predictability - We have turned our Agility Volume Knob heavily toward agility. We want to move and respond fast for our customers at the expense of medium / long term predictability.
Who Attends
Our company is still small enough that sprint planning is an open invite for the company. All you need to do to attend sprint planning is to show up and take a seat (note: finding a seat has been getting increasingly hard lately). I like to say: “Product management is a company, not a department.” By this I mean: ensuring a company builds a product that matters is not something that is limited to a single person or team - but the job of everyone in the company. The next great epiphany in your product can come from anywhere - so we are wary of restricting attendance.
The Release Cycle
We break down our software development into four seasons in a year (Spring, Summer, Fall, Winter) that align to quarterly boundaries, with each quarter consisting of six two-week sprints. The seasons are used to drive major themes (a.k.a. epics) we want to achieve as a business. The sprints are time-boxed units of execution in which we drive work product to achieve these themes, as well as support the more tactical activities required to sustain an active product line. The sprint boundaries is just a logical unit for us though, since we continuously deploy, using both a customer lab and feature flags to get as close to continuous flow as possible.
When We Plan
Our sprint planning occurs every other Wednesday, starting at noon. Due to the time, everyone usually walks into the conference room with lunch. Our sprint planning is also coordinated to directly follow our 11 AM retrospective, so we flow right from the retrospective on the previous sprint into planning for a new one.
The Two Phases
Our sprint planning has two phases: the business phase and the technical phase. The line of demarcation between these two phases has provided us a simple to solution to a classic problem of sprint planning: enabling broad cross-functional engagement. Too often sprint planning gets viewed as something engineering and product management do, and not a place where the rest of the organization can drive the critical discussions and decisions required to build a successful business.
The business phase includes reviewing the results of the previous sprint, the season priorities, and recent customer feedback. It’s goal is to provide the necessary guidance and steering required to plan the next sprint, and its output is the guardrails for the subsequent technical phase. This part of the meeting usually lasts about an hour, and is attended by all.
The technical phase (a.k.a. “the sausage making”) is usually attended by only the battle-hardened sprint planners, which are suspiciously dominated by engineering. The goal is to prepare the board for the next sprint, which includes a backlog review, story assignments and workload balancing. While everyone is welcome to attend this phase, we frequently see our CEO and VP of sales head for the door around this time. This part of the meeting usually lasts for about 60-90 minutes.
Preparation for Sprint Planning
We actually have two backlogs:
- Backlog - This is a prioritized list of stories that are consistent with the business priorities for the season and should be considered for the next sprint planning. This list is curated by the product owner (me), and kept to a manageable size.
- Not In Backlog - Every story not being considered in sprint planning goes into our Not In Backlog, where it will awaits being brought to the Backlog by the product owner, or by a team member who wants to discuss the story in the next sprint planning.
At our current capacity, we have found we can execute about 80-90 stories in a sprint, and so try to keep our Backlog to about 110 stories, and our Not In Backlog to about 2x this. So prior to sprint planning the product owner needs to:
- Review all recent customer requests, and make stories if appropriate.
- Review / prioritize all stories, identifying which ones should be considered for the next sprint.
- Define a list of proposed high-level priorities for the sprint, which are subject to review in sprint planning.
- Prune the backlog back to a manageable size (we announce the archiving of stories a few days in advance so people can salvage ones they feel strongly about).
- Announce to team the completion of backlog prioritization, so others can pull stories into lane they want discussed.
With the exception of requirements definition, most of this work gets done the morning of sprint planning.
Tools
Our agile board is currently captured in Trello. I’ve used many alternative products over the years, and personally dislike them all (with a special hatred in my heart for Jira). In general agile boards either try to enforce a prescriptive process, or work like they were designed for working at Fidelity. Trello is not really an agile board as much as it is a simple way to manage lists. But with a little lightweight process around it, presto, you have an agile board that doesn't suck... well, at least not as much as the alternatives.
What We Don’t Do In Sprint Planning
Here are some things we don’t do in our sprint planning process.
Agile Bookkeeping
We don’t review velocity metrics, story point, burndown charts, or any of the standard agile bookkeeping. I’ve done all this before in previous organizations, and it has provided no value to myself or team. If I worked in a big company like Fidelity, I might do this. But I don’t work for Fidelity.
Prioritize Infrastructure Stories
Having engineers debate with product managers the relative priority of a feature versus an internal improvement just seems wrong to me. If you’ve hired good engineers and wired them to the business / customer, you should listen to them when they tell you there is an investment that needs to be made. We use what I call the “20% rule”, which is sort of my “Don’t Ask, Don’t Tell” rule for infrastructure investments. If engineering needs an investment that takes more than 20%, let’s discuss the need to increase the “20% rule” in the business phase of sprint planning. But let’s never argue whether we should build a feature at the expense of an architecture investment.
Review Infinitely Growing Backlogs
Some product owners manage their backlog like a hoarder, as though each story represents a thread of institutional memory that could be forever lost. If you’re engaged in constant communication with your customers, operate with transparency, and engage cross-functional teams in sprint planning, nothing important will ever be lost for long. We have found that we can at most execute about 100 stories in a sprint, and so try to maintain a backlog that is about 2-3x this. This means we regularly delete stories from our backlog, knowing that they may some day return when they are important to our customers.
Tightly Controlled Sprint Goals
While I do strongly believe in the lessons I took from the “first Scrum team”, I’m not much of a practitioner of Scrum. One area of disagreement I have is with the tight control over the contents of a sprint. Our business moves too fast and our customer feedback is too continuous to limit our ability to affect change to every two weeks. The output of our sprint planning is a rough approximation of what we expect to deliver, and can be changed based on the needs of the business. To limit the switching cost impact of changes to a running sprint, we delegate decisions around these to engineering via an extension to our standup process.
The Business Phase
The business phase consists of the following steps:
- Review the previous sprint
- Review the status of the current season
- Discuss planned strategic agenda items
- Review customer feedback
Review the Previous Sprint
The first step is to review of our previous sprint. This involves walking down the list of committed features in order of priority and having the assigned engineering owner(s) provide an update on the status of the feature. If a feature shipped in the sprint, the status is often short. If a feature did not ship as committed, there is usually an interactive discussion. Anyone can ask a question or voice an opinion here. The key is to have an open discussion to ensure the entire team understands what we did or did not accomplish in a sprint.
As one engineer said to me one day: “There is no place to hide in our engineering team.” If you make a commitment to deliver a feature, everyone from the CEO to your teammates will know its status.
Review Status of Season
We maintain a separate agile board for our themes / epics for a season. Our epics have defined and reviewed high level requirements, which we like to keep somewhat loose since we execute a form of customer-driven development. We review the seasonal priorities, discuss whether there are new themes that we need to consider mid-season (note: happens rarely but has happened), and debate whether we should be changing the priority of existing themes. The output of this phase is a prioritized epic board, that provides priorities for the upcoming backlog review.
Discuss Strategic Items
If there is a desire to discuss a more strategic topic - e.g. a new theme we should consider for next season - we will use this phase of sprint planning to discuss.
Review Customer Feedback
We maintain a running customer enhancement document, which maintains a prioritized list of targeted enhancements directly requested by customers. The use of a shared document instead of adding stories to the backlog is intentional. In a backlog of a few hundred items, the voice of the customer gets lost. But in our shared document, we review new / delivered requests every sprint planning, and the entire list every season. In many ways, this is sort of a mini-backlog review - but one in which a VP of sales and CEO can directly engage and contribute to.
We start by reviewing the customer enhancements that were delivered in the previous sprint. Usually there are about 4-6 customer enhancements that get delivered every sprint. Next we review the feedback our customers provided us in the last two weeks. This will typically include 15+ features and enhancements that they would like to see in our product. The person who collected the feedback from the customer talks to the request, and then we prioritize it relative to all other customer enhancements. In some cases we flag requests as needing more detail, which we take offline for a more detailed discussion with the customer.
Customer enhancements in the upper fourth of our list will typically make it to our backlog. The rest will remain in our customer feedback document for a future sprint.
The Technical Phase
The technical phase consists of the following steps:
- Discuss proposed sprint priorities
- Review work in progress
- Review backlog
- Balance workload
- Make commitments
Discuss Proposed Sprint Priorities
The product owner enters sprint planning with a proposal for the priorities for the sprint. This is a loose list of features we want to deliver in the next two weeks. The product owner is not responsible for deciding on infrastructure investments, so those come from engineering (note: we recently starting experimenting with a rotating role of infrastructure owner, which is effectively a product owner for non-customer facing features).
Review Work In Progress
We start the backlog review with a review of all work in progress. Our goal is to make the decision of whether to allow this work to continue into the next sprint, or to push it to the backlog for review.
Review Backlog
We then start the actual “sausage-making”: the review of our backlog. As mentioned previously, we actually have two backlogs: the Backlog and the Not In Backlog. We only review the former here.
We review each story serially in order of backlog priority. If we decide to pull an item from Backlog to our To-do lane for the new sprint, we assign the story an owner(s). In general, engineers volunteer for assignment, but sometimes they are "volunteered". We actually had an odd new trend appear in our last sprint planning in which engineers volunteered other engineers (sort of like being voted off the island in Survivor). ;)
Balance Workload
Once the backlog review is complete, we review each engineers’ board to adjust the priorities of their stories, and move stories between owners to better balance the work. We also identify committed stories at this point, which are customer-visible features that we want to commit to deliver in a sprint. Commitments are made with minimal planning, so the accuracy is not high - but in general, we deliver most of what we commit in a sprint.
Make Commitments
The last step of sprint planning is an email that goes out to everyone post-meeting announcing the prioritized commitments and owners for the commitments. At this point everyone is aligned on what we are working to deliver, document and roll out to customers in the next two weeks.
At this point, 2-2 1/2 hours of time have elapsed, and we all leave the conference room to start executing the sprint.
Last Thoughts
I'll admit to not believing there is any single right way to run a sprint planning meeting. This process however seems to be working for our company at this point in its life. As our needs change and our customer base continues to grow, we will need to adjust this process to support our new requirements.
I used to work with an engineer who said: “If you haven’t written down your process somewhere, you don’t have one.” I guess now I can say I have a process.
Related Posts: 8 Lessons From the First Scrum Team, Finding the Minimum Viable Feature (MVF)