7 Ways to Decide if Scrum is Right for Your Team

As you get ready to start working on a new product or you’re looking to shake things up with how your team works, you have a lot of options to pick from.

Your team wants some structure in their methodology, but not so much that they’re stifled. 

You’ve heard about the scrum framework and think it may work for your team, but you want to make an informed decision. To help you out, here’s a brief description of the scrum framework and seven ways to decide if scrum is the right framework for your team.

What is Scrum?

Scrum is the most commonly used agile software development framework. Jeff Sutherland and Ken Schwaber initially developed the Scrum framework in the mid 1990’s based on their work and the ideas contained in an article published in the Harvard Business Review in 1986 by Takeuchi and Nonaka entitled “The New New Product Development Game.”

There are three principles that form the foundation of the scrum framework: transparency, inspection, and adaptation. Even though it started as a framework for software product development for product managers, it does not dictate any particular software development practices. That means you can use the scrum framework to guide work in other fields including research, sales, product marketing and advanced technologies.

The scrum framework does identify a small set of roles in terms of who forms a scrum team. Those roles are:

• The scrum master, who acts as a process coach for the team.
• The product owner, who is the product person on the team and focuses on what the team will work on.
• Developers – everyone else on the team who delivers the increment of the product.

The scrum team interacts in a collection of events that provide a regular cadence for the team to follow. Those events are:

• The sprint: the set timeframe (usually 1 – 4 weeks) in which the team produces an increment of their product.
• Sprint planning – the discussion at the start of the sprint where the scrum team agrees what they’re going to work on during the sprint.
• Daily scrum – the daily discussion the team uses to coordinate their activity. 
• Sprint review – the event at the end of the sprint where the scrum team discusses and demonstrates their progress with customers and stakeholders.
• Sprint retrospective – the event at the end of the sprint where the team reflects on the sprint and identify opportunities for improvement.

During the course of the sprint, the scrum team produces a small collection of artifacts:

• Product Backlog – a set of options the scrum team can pick from to build and improve their product.
• Sprint Backlog – the user stories and tasks that the team plans to deliver during the sprint.
• Increment – the portion of the product that the team delivers during the sprint.

With that overview of scrum in mind, lets take a look at when scrum makes sense for your team.

When does Scrum make sense for your team?

Just because scrum is the most well-known and widely used agile framework does not mean that you should always use scrum exactly as it’s described. You may find that there are times where you combine aspects of the scrum framework with other techniques to best suit your particular situation.

Deciding what approach to use is not a matter of agile vs scrum. Scrum is one way to implement an agile approach.

So with that in mind, here are seven things to consider when deciding whether your team uses a scrum board or some other approach.

1. Do you have a small, cross functional team?

When you have a small team, usually under 10 people, that consists of the skills needed to deliver your product, scrum may be a good option for your team. 

You’re in even a better position to use scrum if each of your team members is able to do multiple things. Your team members may have a speciality, such as front-end development or devops, but they’re also willing to help out others when needed. 

2. Is your team able to self-manage?

Scrum places a huge emphasis on the team managing their own work with the help of a process coach in the form of scrum master. In fact, the main purpose of the events detailed in the scrum framework are to provide the team a mechanism for managing their own work.

To successfully implement scrum, your team needs to be able to manage themselves without much guidance from outside.

3. Do you have a readily available product person?

The other key aspect of your team composition that indicates a proper use of scrum is a fully available product manager. You need someone who is able to make decisions about the team will and will not work on. You also want that person to be available to answer questions with a fairly quick turn around so that the team is not sitting around waiting for answers and decisions.

4. Is there uncertainty in your requirements?

If you lack clarity in the specifics of your solution – and let’s face it, uncertain requirements are a hallmark of software product development – then scrum is an approach worth investigating.

The short feedback cycles built into the scrum framework make it a great approach for dealing with uncertain requirements. These feedback cycles allow you to dig into detail on a small portion of your solution, deliver that solution and then collect feedback which you can use to define the next portion of your solution.

5. Do you need to test your solution?

Those short feedback cycles provide an excellent opportunity to test your solution and modify it based on ongoing feedback from customers and users.

Remember, the product backlog represents a collection of options you can try to help your customers solve a problem. Your team can deliver a potential solution to your customer in a sprint. Then you can use feedback as people use that solution to determine if it solves their problem, or if you need to try a different approach, which you can deliver in subsequent sprints.

6. Do you have flexibility in your scope?

In order for a team to work through requirement uncertainty and to test their solution as described above, they need to have flexibility in their scope. You may have defined scope in terms of the broader problem you’re trying to solve, but you don’t necessarily have a defined list of the exact things that have to be delivered.

What’s more, you can use a scrum tool to work on a fixed cost, fixed time effort if your team has the ability to flex the scope they are expected to deliver.

If you’re in a situation where you’re expected to deliver a tightly defined scope within a constrained time and budget, your chances of being successful are fairly limited, regardless of what approach you use.

7. Do you have a non-trivial amount of work that can be split into smaller chunks?

The work of your software development team can reliably take on one of two forms. Understanding which form of work your team deals with can provide some guidance into the choice of scrum vs kanban.

If you’re building a new product or are introducing a significant new feature to an existing product, you have a large chunk of work that you need to split into smaller bits that you’ll deliver incrementally. In that situation, scrum is probably a good bet for managing your work.

If your team’s work arrives unpredictably on a day by day basis, such as when you’re primarily providing maintenance and support for a product, you may be better off using a kanban approach.

A team using scrum identifies the things they are going to work on at the beginning of the sprint during sprint planning and take great strides not to change that set of work during the course of the sprint.

Kanban on the other hand tracks work one piece at a time which allows for more flexibility to adjust the next thing the team works on.

Final Thoughts

The scrum framework is a structure used for organizing and managing the moving parts of a product development effort. Originally designed for use in software product development, scrum is now used by organizations and teams across all disciplines. 

The framework works well for smaller teams tackling projects with changing deliverables, unknown solutions, and frequent interaction with clients or end-users. Scrum favors incremental and iterative phases of production to deliver functional products faster and with more frequency.

If this situation sounds familiar, then scrum may be the right framework for your team.