Quick and Easy Definitions of Agile, Scrum & Sprints

Quick and Easy Definitions of Agile, Scrum & Sprints

Have you ever worked on a project that was way behind schedule, way over budget, and ultimately resulted in a mediocre product? If so, you’re definitely not the only one.

Many frustrated managers have scrutinized fizzled projects, and conclude they’re often a symptom of a broken methodology. And they’ve worked to develop new and improved ones.

“Sprints” have become a real buzzword in the project management world. At first blush, the word conjures up images of a running track, starting blocks, and athletes in tiny shorts bursting through a finish line ribbon.

In project management, however, sprints aren’t athletic events. Rather, they’re short bursts of work that magically improve a project’s process and its output.

Want to know more about agile project management and sprints? That’s what we’re discussing in this post, so without further ado, let’s get into it.

A Recent History of Project Management

In the past few decades, some of the most significant changes in project management have come out of the software industry.

Waterfall: A Definition

Back in the 80s and 90s, software developers used a project management method called waterfall.

Waterfall is a fixed, top-down approach to managing a project. The leader establishes the timeline and the budget, and the team falls in line behind him or her. Gantt charts typically are utilized with waterfall, with each step of the project carefully plotted out and recorded.

The Problem with Waterfall

Although waterfall is useful for certain types of projects, in many instances the method creates nothing but trouble.

The software developer Ken Schwaber, in his book Scrum: The Art of Doing Twice the Work in Half the Time, expounds on his experience with waterfall:
“The process was slow, unpredictable, and often never resulted in a product that people wanted or would pay to buy.”

“Step-by-step plans…reassured management that we were in control of the development process—but almost without fail, we could fall quickly behind schedule and disastrously over budget.”

What is it about waterfall that creates this sort of mess? The development team works to complete a contract, and never communicates with the client during the project. Its rigid, fixed approach doesn’t allow for reflection and course correction.

Have you ever been frustrated by a software system that wasn’t at all user friendly? In all likelihood, it was created using a waterfall approach. During its creation, the development team never paused to test the software on potential customers. Rather, they listened to the directives of the project manager, then worked from start to finish with horse blinders on.

It’s no surprise, really, that this approach results in a sloppy product nobody wants to use.

Agile: The Solution

In the 90s and early 2000s, software developers started discussing their frustrations with waterfall.

Intent on finding a better way, a group of them put their heads together and wrote the Agile Manifesto.

The manifesto places values on “individuals and interactions over processes and tools” and “responding to change over following a plan.”

Agile sought to resolve fundamental problems with waterfall. It encouraged collaboration with the client throughout a project, daily face-to-face communication, autonomous teams, and frequent reflection.

Although initially agile was utilized exclusively by software developers, within a decade or so it started to trend in other areas as well. Currently, it’s not uncommon to see the agile method embraced by construction companies, marketing agencies, and even by families to assist with home planning.

Agile & Scrum

The essence of agile is producing work in small batches, reflecting and then plotting a path forward. Whereas waterfall might be compared to an unbending rod of steel, agile is more like a flexible branch, or a malleable piece of clay.

An agile process allows for change and adaptation throughout the project, even late in the game. An agile team consistently shares its work with the client and other stakeholders and uses the feedback to chart a path forward.

The agile manifesto says that teams aim to: “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”

Scrum is an agile system developed by Ken Schwaber and Jeff Sutherland. It was inspired by an article in The Harvard Business Review in the 80s, written by two Japanese professors.

The scrum method lays out clearly defined roles, ceremonies, and artifacts. The scrum framework allows a team to plan a project around agile principles. One of its central ceremonies is a sprint.

The Skinny on Sprints

In scrum, a “sprint” represents one iteration or rotation of a project. During this iteration, a team completes a designated amount of work.

Generally, a sprint lasts two weeks, but it can be as short as a week, and some teams even design sprints that last only one day.

A series of sprints, then, comprises the entire project. The idea is that grouping work into small batches gives teams the space to pause and reflect, regroup, and re-chart the course if necessary.

What’s Needed to Plan a Sprint?

A well-planned sprint requires some tools and key information.

A Backlog

Every scrum team needs a backlog. A backlog is a record of all the work necessary for the completion of the project. Grooming the backlog and prioritizing the most pressing work falls to the role of the product manager.

Story Points Assigned to Backlog Items

The next task is to assign “story points” to each item in the backlog.

A story point measures the amount of work each item in the backlog represents. These points allow teams to select an appropriate amount of work for each sprint. Story points always are estimates, and assigning them is an activity teams do together.

This point value isn’t a measure of time, but rather a measurement of output. (The research has shown that time estimates are often inaccurate. The amount of time it takes to complete one task can vary greatly depending on who is doing the work and when the work is completed.)

Teams that have worked together for a while develop a good sense around the number of story points they’re able to complete over a sprint. This number is referred to as its velocity.

How to Plan a Sprint

At the beginning of a sprint, the team comes together for a sprint planning session. At this session, everyone looks at an overview of the project, with the objective in mind. They consider any updates, client feedback, and other stakeholder input.

Next, they look at the product backlog and identify the work that’s going to make significant progress toward the goal. An objective is to eliminate busy work, and identify tasks that are both high priority and essential to the project’s completion.

Independent teams are a trademark of agile. And so on its own, the team selects work and assigns tasks to specific people.

When work has been selected and assigned, the team officially begins the sprint.

How to Conduct a Sprint

Throughout a sprint, teams meet daily at a scrum meeting. This brief meeting is an opportunity to discuss any impediments or blockers to completing the sprint.

During the sprint, an agile team may swarm around a certain task to bring it over the finish line. This means that everyone on the team focuses exclusively on that task until it’s completed.

How to Complete a Sprint

The completion of a sprint is a significant stage in the process.

First of all, the team presents what it’s created to the client, for feedback. This step signifies a crucial difference between agile and waterfall. It allows the client to determine if the team is working in the right direction; if they’re in fact developing what the client has asked for. The team carefully considers the feedback when it plans its next sprint.

Next, the team, on its own, participates in a “retrospective” ceremony. The essence of the retrospective is to identify things that went well, and to discuss things that could be improved for the upcoming sprint.

This briefly captures the essence of a sprint and its processes. How do teams and projects benefit from sprints? Let’s discuss this next.

The Benefits of Working in Sprints

In the same way that short bursts of exercise improve your health, sprints improve a project in all sorts of ways.

Increases Collaboration

The Agile Manifesto says to “build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

Agile teams are autonomous and self-motivated. On its own, the team prioritizes work in the product backlog and then selects and assigns work during the sprint. The daily scrum and swarming sessions during a sprint further increase cooperation and bonding within a team.

Creates Opportunities to Improve the Product

When a team is myopically focused on bringing a project over the finish line, creating a superb product becomes a secondary priority.

On the other hand, working in short iterations creates opportunities to pause, assess, and make adjustments. Working in sprints ensures that the project continues on the path to success.

Leads to a Happier Client

Sometimes a client doesn’t even really know what she wants at the beginning of a project. Or her requirements change mid-way.

Agile “welcomes changing requirements, even late in development,” and sprints create continuous dialogue between a team and the client, to ensure the product is really going to deliver what she wants.

Focuses the Team’s Energy

Taken all at once, a project can feel immense and overwhelming. Sprints allow a team to focus on more manageable amounts of work. This sharpens its focus and buoy’s its energy.

Carefully choosing tasks during a sprint planning session also eliminates the time a team spends completing busy work and going down rabbit holes.

Saves Money

Planning work in small batches and reflecting generally reduces the need to backtrack, rip things out and start over.

Rather, the team has already reflected and pivoted (if necessary) and so each sprint is a step toward the finish line.