An Introduction to Sprints and Sprint Planning
Life is full of complicated projects — event planning, construction, and, yes, building a website. This introduction to sprints and sprint planning will illustrate how we keep it all moving forward.
Life is full of complicated projects — for example: planning a large event, constructing a road, or building a website. Just thinking about all the checklist items and variables can make your head spin, and it’s overwhelming to know where to begin.
Which is why it’s often easier to break complicated work up into smaller, more manageable pieces.
For example, when planning an event, you’re likely going to start by first establishing a budget and date, which can then help determine a location and activity details. In road construction, it’s common to finish one side of the road before beginning the next.
The same concepts apply when building a website. At Blend, we follow industry standards by carefully planning out the scope of work and then creating a plan to develop and deploy the work in short bursts. We do this by using sprints.
Sprints and sprint planning.
If you’ve worked with Blend before, you’ve likely heard the term “sprint.” No, we’re not over here running through the halls, competing for the best time. Instead, sprints are used to help break up, plan, and schedule the work our team is completing each week.
What is a sprint?
Think of your project as a marathon, and each sprint as the individual segments that get you closer to the finish line. Sprints are a set amount of time our team has to complete their work. The length of a sprint can vary depending on the frequency that works best for the company, but sprints are commonly one or two weeks. We found that one-week sprints work best for us at Blend.
Why do we use them at Blend?
Sprints are part of the Scrum and Agile workflows. It allows us to break down a large project into weekly work, which helps our team more effectively prioritize the work that needs to be done. This helps our developers focus on specific tickets, rather than picking and choosing from the long list of tickets in the project.
Just as important, sprints make it easier for our team to make adjustments, or address concerns right away. Because we’re working one week at a time, sprints help keep things moving forward, while still allowing movement to shift priorities. Weekly deadlines help encourage developers and designers to bring up issues and collaborate with the team to find a resolution within that sprint, rather than waiting until it’s too late.
What is sprint planning?
So how do we decide what to include in each sprint? Sprint planning.
Sprint planning is a set collaboration with the full project team to review priority tasks and the estimated effort needed to complete them.
In an ideal world, the tasks in a ticket are completed within each sprint. But some things just take more effort than others. Or, perhaps, a larger or more complex feature or design may not make sense broken into smaller tickets, so it is tackled over multiple sprints. Finally, each developer works at a different speed, which means progress hinges on several potential external factors.
Sprint planning allows the team to review progress, adjust priority, and understand individual developer velocity. Combined with a backlog of tickets and and understanding of individual developer velocity, the team can use sprint planning time to aid in making future sprints successful.
What is Blend’s Sprint?
Here’s a little look behind the scenes here at Blend.
Blend works in one-week sprints that run from Wednesday to Tuesday. We end our sprints on Tuesday, rather than Friday, because we would rather deployments and meetings happen during the week, rather than on a Friday afternoon.
Our naming convention uses the last date in that sprint as the title. This is when we expect the work to be completed. For example:
- The May 7th Sprint is planned for all work to be completed by May 7th.
- This means work begins on the Wednesday before - May 1st.
Let’s say that, during sprint planning, we decide the May 7 Sprint will be used to complete a basic page — a “general use” landing page, for example. We estimate this will take one sprint. We also identify a more advanced content type — a complicated news feed with filtering and categorization, for example — that will take two sprints. We’ll start the first half of this page in the May 14 Sprint, with completion in the May 21 Sprint.
On May 1st, work begins on this About Us page. During our weekly check-in, our client informs us that the news feed page will require a form integration that they’d like to begin testing, so they’d like to move it up in the schedule. In other words — it’s time to adjust our priorities.
If this happens early in the sprint, we may be able to shift development over to this different page. In this case, if caught early enough, we can swap the two page types and schedule the news feed for completion in the May 14 Sprint, and then move the general use page to the May 21 Sprint.
If this change occurs later on in the sprint, maybe the Project Manager brings in another developer from a lower-priority project into this one. In the next sprint planning meeting, adjustments would need to be made to rearrange priorities. Even with multiple projects and changing priorities, we are able to use sprints and sprint planning to shift our goals without sacrificing the overall project timeline.
Staying on schedule means being agile.
Website development is complex. On the surface, a website is a collection of pages filled with different features, content types, and styles, but by digging deeper, you’re likely to find several programming languages, server environments, and databases all working behind the scenes to make the website work.
While it might seem overwhelming, there's always a way to get things done by breaking them into smaller, bite-sized pieces. Sprints and sprint planning help make sure these pieces aren't forgotten — and make it much easier to successfully plan and deliver complicated projects.