If you are reading this piece in 2020 as a member of an engineering/cross-functional team, chances are that the team you are on uses some mix of waterfall, scrum and kanban principles for planning. But what does that mix look like? Is it working well for the team, or is it getting in the way of product development?
This article attempts to describe the "Ideal Sprint" or well, to put my thoughts down on what I've seen working well during my years as a software engineer and engineering manager.
When I think about what makes sprints efficient, my thoughts are usually around these goals:
Let's start with a few rough definitions:
Now that we got most of the definitions out of the way, let's take a look at what processes the team follows and the lifecycle of stories.Frequency: once every two weeksLength: 30 minsOwner: scrum master
Every other week, the team has a backlog refinement session. The goal of this meeting is to estimate any new stories and change their order (priority) in the backlog. To get the most out of this session, the scrum master has to prepare: they need to know what stories will be estimated, and if the stories have enough context so the team can estimate them. If not, the scrum master has to ask for clarification before the meeting takes place. If by the time of the backlog refinement meeting there is not enough information to estimate a story, the team skips the story.
The estimation of a story may go something like this:
Frequency: once every two weeksLength: 60 minsOwner: scrum master
When a team adopts estimation that never did it before, it may be helpful to think about story points as time estimations: one story point for one day of work should do. After a few sprints, the team can slowly move away from the time estimation and start trying to assign story points based on each story's complexity.
This meeting consists of two parts. The first part is a retrospective for the sprint the team is about to close and the goal of this part is to give kudos and discuss problems. The group spends the first few minutes highlighting what went well and what needs to be improved by collaborating on a shared document. After five minutes, or when folks stop typing, the scrum master starts going through the items, and the team briefly discusses them. One of the most important parts of this meeting is to discuss what needs to be improved and assigning clear owners of the action items.
The second part of this session is sprint planning, with the goal to understand the team's velocity, and what will be the main focus for the next sprint.
You could follow an agenda similar to this:
Frequency: twice every weekOwner: scrum master
You can use this template to keep track of retros and sprint plannings. The planning section is filled out during sprint planning, and the retro section is filled out during the Retrospective meeting in two weeks. So in practice, you'll edit two of these documents during this meeting, one for the past sprint, and one for the next one.
As most of us have a slightly (or vastly) different schedule, daily standups can be challenging, especially if you are part of a globally distributed team. Instead of doing daily standups, I prefer doing standups twice a week, using Slack.
It has the following benefits:
I found it best to start sprints on Mondays and close them the next Friday. This way, calendar weeks directly maps to sprints, without any cognitive overhead (like starting sprints on Wednesday).
With this in mind, a calendar for a sprint for a scrum team may look like this:
Now that we covered the definitions and the meetings involved in efficient sprints let's also recap the lifecycle of stories.
Every story is created equal - we do not differentiate between bugs, feature work, or discovery (spike). They go through the same estimation and prioritization sessions. This way, the team can better plan each sprint the amount of work they can take on.
Okay, okay, but how does this process fit into quarterly/semi-annual planning cycles?
Ideally, in your planning cycles, you set goals using OKRs. These goals will be the primary inputs for your prioritization discussions during sprint planning and backlog refinement.
Another question that can also come up when following this framework is how the team will meet deadlines?
Taking a look at the team's average velocity and summing up the estimations for stories required for a feature or release gives a relatively accurate picture of when a team can ship a feature. Estimations also empower the engineering team to help decide what parts could be cut to make a deadline.
I realize that these answers barely scratch the surface, but they deserve an article of their own. Be on the lookout, I am planning to work on them next!
By following this framework, you can create a streamlined sprint planning process that only adds less than an hour of meeting overhead to the team's weekly schedule: the backlog refinement takes only half an hour. The joint retrospective and sprint planning meeting an hour.
I am thrilled that we created this sprint planning framework - it saves the teams following it countless hours spent in meetings, and helps them keep focused. It also reduces the friction caused by annual, semi-annual, or quarterly plannings.
Special thanks go to Chase Starr, who contributed a lot to the framework I described above!