Agile product management is one of those terms that we see so often that people rarely stop to define it. So, before we discuss how product teams can use the Scrum framework within agile, let’s review agile product management itself.

What is Agile Product Management?

The agile concept was created as a framework for software development teams. The approach emphasizes team collaboration, incremental progress, and continuous learning.

With increased competition in many industries and customers demanding new innovations, many organizations have adopted an agile product management approach. Applying the agile framework to product management lets companies release regular updates of their products and learn with each small update what resonates with users, rather than having to build the entire product first and then release it to the market.

What is Scrum?

Agile is more of a mindset than any specific development rules or steps. Dozens of agile frameworks have emerged to help organizations adopt their preferred type of agile approach. Disciplined Agile (DA), the Scaled Agile Framework (SAFe), and Lean Software Development (LSD) are just a few of many examples.

Another popular agile approach is Scrum; a lightweight project-management framework developed to help companies create, deliver, and sustain complex products. Using the Scrum agile framework, product teams break down their plans for long-term projects into short-term periods of work called sprints. Each sprint is time-boxed, limited either to two weeks or one month.

During each sprint, the development team works on only a few agreed-upon projects. If a project requires more work than the team can complete in a single sprint, they will break up the work into several sprints. The goal is to update the product frequently and to release those updates to the market often as well, to learn what resonates with users continuously.

What Does a Scrum Team Look Like?

The Scrum team includes several roles:

Product Owner

This member of the team is responsible for making sure the developers are working on the right items and doing so efficiently. The product owner is also responsible for managing the product backlog.

Scrum Master

The Scrum Master is responsible for overseeing the development team, guiding and coaching the developers, and helping to clear any obstacles that could disrupt or slow down their work.

How does Scrum Work?

A typical team’s Scrum agile approach will look like this:

Scrum Events

1. Sprint Planning

The team meets to review the product backlog, select the items to work on for the next sprint, and agree upon the strategic goals of the upcoming sprint.

2. The Sprint

This is the primary unit of development work in the Scrum agile framework. Most teams schedule sprints for two weeks or one month, and during those periods, work only on the items agreed to in the sprint planning session.

3. Daily Scrum

These are sometimes called Standups, or Daily Standups. They are very short meetings, typically 15 minutes, held each morning of a sprint to discuss everyone’s planned work for the day and to address any issues or obstacles that could affect that work.

4. Sprint Review

This is an informal meeting held at the end of a sprint, where the team reviews its completed work against its plan for the sprint and adjusts the product backlog if needed to add uncompleted work to the next sprint.

Scrum Tools (sometimes called “artifacts” in scrum)

1. Product Backlog

The comprehensive list of product tasks that the cross-functional team has decided to work on eventually. As they plan for each upcoming sprint, the team will start by reviewing items on the product backlog.

2. Sprint Backlog

When the team identifies items on the product backlog that it deems worthy of working on during the next sprint, they will add them to the sprint backlog. These decisions typically take place during the sprint planning session.

3. Sprint Goal

After the team has agreed on the tasks for the next sprint, they will collaborate on drafting a short sprint goal. The goal articulates the strategic objective of the next sprint and offers a clear way to measure success.

3 Pitfalls Scrum Teams Fall Into

Now that you have a sense of how the Scrum agile framework works and who’s involved, and how it works, let’s review some of the dangers to avoid in setting up your product management team’s Scrum approach.

Pitfall #1: Calling it Scrum… but not actually doing Scrum

The Scrum agile framework has gained popularity with product teams across many industries. It can lead organizations to eagerly start using Scrum—or something that looks like it—before they understand how to implement the framework.

There are many signs you’re not really doing Scrum. For example:

• Your developers work mostly on the agreed-upon tasks during a sprint. However, the Scrum master lets them take on other projects as well.

• You don’t hold sprint retrospectives with the entire team after each sprint session. (This, after all, is the best way to review the team’s progress together and to identify what processes work and which ones don’t.)
• You don’t have a true product owner. When product managers, for example, take on the role of their agile team’s product owner, they often find it just doesn’t work. In a Scrum, agile product management environment, the product owner’s responsibilities are important and time-consuming enough that it should be a standalone role.

Pitfall #2: Letting your Scrum team get too big

The official Scrum Guide, written by Scrum’s co-founders Jeff Sutherland and Ken Schwaber, recommends that a Scrum team should consist of between three and nine developers. The count doesn’t include either the product owner or the Scrum master unless they’re also doing some of the development work.

Why does the guide specify that you keep your Scrum team within this size range? Fewer than three developers will mean less collaboration and interaction, which will undermine the team’s productivity and creativity. And if you let the team grow to 10 or more developers, that will require too much coordination and will be more likely to create confusion and miscommunication.

Pitfall #3: Skipping Scrum ceremonies

The Scrum events described above—the Daily Standup, the Sprint Retrospective, etc.—help a Scrum team stay focused and disciplined. But when people get busy or feel pressure from around the organization to move the product’s development forward more quickly, agile teams can fall into the trap of skipping some of these Scrum ceremonies.

Scrum’s founders devised those ceremonies for a good reason. They keep the team communicating at regular intervals about the right things. They give everyone on the team opportunities to voice concerns or ask for help removing barriers that are making it challenging to complete their work. And they allow the team to learn together what aspects of the process are working and which ones need improvement.

In other words, skipping these ceremonies can turn an otherwise high-functioning Scrum team into unorganized chaos.

Read our free Agile Product Management book >