With so many product development teams using Scrum today, it’s important to understand its nuances as you begin your career.
When you join your first software development team, you’ll quickly get adjusted to the principles of agile methodology. Collaborative, iterative, and user-focused, agile methodology is a modern software development process that encourages flexibility.
Agile is an umbrella term that includes several management frameworks to help development teams plan out how they will get things done. One of the most popular Agile frameworks is called Scrum. “Empiricism was at the heart” of Scrum’s modern development, said Dave West, the CEO and product owner at Scrum.org. “How can you predict something that you don’t know? The only way … is to do a little bit of work and to inspect it and adapt,” he said.
Product development teams use Scrum to “manage complex projects with unstable or rapidly changing requirements by providing a set of techniques … to embrace their complexity and timely address rapidly evolving needs,” said Uladzimir Sinkevich, head of Java development at ScienceSoft. Scrum allows teams to make discoveries and quickly pivot projects while delivering potentially shippable software to stakeholders on a regular basis. Scrum helps teams to ensure that they are working toward creating products that people will actually use.
If you’re a junior engineer ready to join your first team, this primer will give you a foundational understanding on how and why development teams use Scrum.
Scrum is a light framework that helps teams break down large, complex projects into smaller production goals that can be quickly delivered to stakeholders. “What needs to be built has a tendency to evolve over time,” said Erik Gfesser, principal architect at SPR Consulting. Scrum gives teams “a chance to change direction as needed rather than marching toward a distant deadline,” he said.
Before Scrum became widely popular in the early 2000s, companies created products through highly structured and sequential development methodologies, which resulted in some products that were already irrelevant once they hit the market. In the 1986 Harvard Business Review article titled “The New New Product Development Game,” Hirotaka Takeuchi and Ikujiro Nonaka suggested that teams needed to adopt a holistic, rugby-like approach where they worked together as a unit “passing the ball back and forth” to reach a goal.
Scrum allows developers and stakeholders to share continuous feedback, and to course correct while changes are still easy to implement. Scrum involves “three very simple tenants,” West said. “One is empiricism, the other one is self-organization, and the third one is continuous improvement. You’re always trying to get better.”
“The core of Scrum success resides in a self-motivated team,” Sinkevich said. The Scrum team includes a
The Scrum team works together in what are known as Scrum events. These include
A sprint. You can think of this as the container that holds all the other Scrum events. A sprint is timeboxed, which means that once a sprint starts, its deadline does not change. A sprint lasts between one week to one month. These short time frames help teams to efficiently tackle the complexities of software delivery. “There are so many variables that make [software development] complex, that it’s impossible to be so deterministic,” West said. “Rather than trying to do everything, let’s focus on a small chunk, call that a sprint. Hey, what’s the goal of this time?”
Sprint planning. At the start of each sprint, the entire Scrum team comes together for a few hours to create a plan. The development team makes decisions on what they can complete during the sprint by understanding the project’s requirements—called user stories—and planning out their work.
User stories are translated into story points during the sprint planning phase to help the development team manage their time. Gfesser said that “story points, in particular, seem to catch many novice software engineers by surprise, who tend to automatically start relating these points to time, as in one story point equals four hours.” Rather than equating a story point within a rigid timeframe, Gfesser said that “story points are intended to be relative within the context of a given development team, which over time will come to understand their velocity.”
When you’re new to a Scrum team, “don’t be afraid to speak openly about the problems you face and ask for the assistance of other team members,” Sinkevich advised. “This is exactly what such meetings are intended for.”
“We used backlog refinement to dive into the user stories that we are planning on working on in upcoming sprints (usually one or two sprints out),” said Thomas Stiehm, CTO of Coveros, Inc. “We do this so that we can make sure the user stories are understood by the team and to get requirements questions answered before the beginning of the sprint. [It’s] also where the team decides not to do stories or postpone stories.”
Sprint review. At the end of a sprint, the Scrum team presents their finished work, called the increment, to stakeholders. The Scrum team discusses what they had, and had not accomplished, from the sprint plan. The stakeholders review the increment and ask questions. Then, the entire group collaborates on what they should do next, such as strategies for how to tackle the remaining product backlog.
A main benefit of a sprint review is for the entire team not only to test the software, but also to consider the usability of features from the perspective of end-users. For many teams, their goals have evolved from not only delivering shippable software to stakeholders, but to “delivering value every sprint,” West said. Sometimes, “you’re actually reviewing not the software at the sprint review, you’re reviewing the telemetry from that software being used and debating why nobody’s using that feature that’s really cool, even though nobody wants it,” he said.
Sprint retrospective. After the sprint review, the development team and Scrum master meet to reflect on their processes. Their goal is to communicate what went well and how they can improve in the next sprint.
Stiehm said that retrospectives help teams to review their work during the last sprint, and to identify improvements for future workflows. “There are dozens to hundreds of retro formats … designed to focus on different areas of the team’s work, such as general practices, interpersonal practices, technical practices, or working with people external to the team. Retros are meant to help the team get better so that we make software better fit for purpose,” he said.
Working within short time frames, teams adopt Scrum to organize, document, adapt, and pivot their processes to better respond to user’s needs and create better products. It is a framework that can also be combined with other types of project management practices, like Kanban.
As you learn more about Scrum, you may find that “there is a lot of advice that is contradictory out there,” Stiehm said. “Once you feel comfortable with Scrum by the book, use retrospectives to tune the process your team uses.” Scrum is about being adaptable to the processes that work best for your team and organization.
“Ultimately, it’s people delivering working product, people that are delivering value," West said. “That’s the reason why Scrum is successful.”
Hannah H. Kim is a freelance writer. You can find her work on AngelList, Fastcompany, and Increment.