I am not here to advertise scrum or convince you that you should use it on your projects. Instead, I want to address a statement I hear a lot among people working in tech: “I hate scrum, and I don’t think it provides any value.” They see scrum as a bloated process forcing them to sit in pointless meetings that keep them from contributing to their projects. Those people are right about their process, but it’s not because of scrum.
Defining Scrum
To talk about using scrum wrong, I first need to outline what it is. At its core, scrum is just another tool in the project management toolkit. It can ensure that you and your team are working on the most important things and consistently delivering value to your stakeholders while getting feedback as soon as possible. Scrum is not daily standups, story pointing, sprint velocities, or sprint meetings.
These can all be useful for running an effective scrum process. However, you should use them in a way that serves the overall goal of making sure you and your team are working on the right things. When used well, scrum provides a framework that allows you to focus on building software while everything else takes care of itself.
The Daily Standup
The first sprint ceremony I’ll address is the one that often comes under the most scrutiny. I’ve heard it described as a meeting where you zone out until it’s your turn to read the title of the current ticket you’re working on. If that sounds like your standup, then you are using it wrong. Standups are not a progress update where your manager confirms that you have, in fact, been doing your job. Instead, they are an opportunity for the team to all get together and make sure the project is heading in the right direction.
Use that time to talk about what work is in flight, investigate any blockers, and figure out if the sprint is on track. When things are going well, this shouldn’t take more than five minutes. When there is a concern that comes to light, then figure out who needs to talk through it and let everyone else leave. If you find that your team doesn’t have anything new to talk about every day then don’t meet every day.
Story Pointing
Another common practice I hear people criticizing is story-pointing. Nearly anyone who has been on a scrum team is familiar with the experience of being trapped in a conversation about whether or not a story is considered “a two” or “a three.” In practice, the most effective next step is to simply pick a number and move on.
Storytelling is not an exact science, and the process has enough flexibility to account for those mistakes. Over a few sprints, the numbers will average out, and a few points here and there won’t really matter. However, if the difference is between two and 13, then that’s probably a great indicator that everyone is not on the same page. Scrum ensures that the process is as efficient as it can be. Story pointing can be a great tool for making sure everyone aligns on the project.
Sprint Velocity
Story pointing dovetails with the idea of sprint velocity. It’s important to call out that sprint velocity is not a target to hit. Instead, it is a measurement of past performance. It’s purely the average points completed per sprint in the last few sprints and gives no guarantees of future performance. It can be a great tool for predicting the timeline of large projects spanning multiple sprints and determining what you can deliver in a given sprint. However, use it as a guide rather than an expectation. If you rely on your team to hit perfect velocity every sprint, then you’ll be disappointed roughly half the time.
Sprint Planning
If you’ve used all of your tools correctly, then a Sprint Planning meeting should be easy. This is the time when teams gets together and make sure they are still working on the right things. Hopefully, you’ve already demoed the work from the last sprint and confirmed that you built the right thing. You should have a backlog of stories that have points associated with them in order of priority. Everyone should be on the same page. Now all that is left is to decide what the team needs to deliver in the sprint. It should probably take fewer points than your velocity to complete, I usually like to keep it around two-thirds.
Hate scrum? Do what works.
Scrum is a tool you can use in many different ways. It’s up to you and your team to figure out what works best. If there is a part of your process that you don’t like, then change it. Sprint retros are a great opportunity to propose changes and try new things. As long as you’re establishing a regular cadence for delivering value to your stakeholders, getting feedback on your work, and ensuring the team’s priorities are aligned, you are doing scrum. Scrum is as customizable as you make it.