Scope Management Techniques in Scrum

Managing scope more objectively can improve quality in scrum teams

Photo by Diego Jimenez on Unsplash

As a reader, we suspect you are at least a practitioner of scrum and are using a popular tool like Jira or Rally. This article is not about tools or what we think may be better choice for managing scope. Instead, we will describe a few process changes that we tried for a few of our scrum teams to manage scope more objectively. These changes have helped us improve the quality and consistency of our product delivery as well as increase collaboration inside the teams. You can try them and see if they can work within your teams or write back to us with questions and suggestions.

Sources of Scope Change

One of the basic concepts in scrum is that the scope of what gets done during a sprint depends on the capacity of the team for the duration of the sprint. As the capacity of the team varies from one sprint to another, this means that the scope of what is delivered in a couple of sprints should not be fixed ahead of time. Though not the subject of this article, doing so repeatedly can cause team burnout, technical debt and quality issues.

Besides, new information can be available towards the end of the sprint or sometimes even during the sprint that can prompt scope changes. In an agile project, this may be the most common source of scope change and a scrum team must take this new information into account to decide the next course of action.

However, it may not always be easy or even possible to accommodate scope changes due to the following reasons:

Why scope changes are usually met with resistance

1. A project may have a launch date or deadline that is not movable. A high level milestone or commitment may need to be met. Changes that threaten this are often met with a lot of stakeholder resistance.
2. It is quite possible that a project has a lot of technical challenges or dependencies that more than often lead to changing timelines. This may make the stakeholders wary of allowing scope changes that they feel could exacerbate the situation.

Options to manage scope changes

So what do we all do in these difficult circumstances that arise way too often? Here are some examples of options that may be illustrative:

1. Don’t change scope.
2. Work extra hard or more hours
3. Pull more developers from other teams or projects.

Let’s look at the outcomes of picking these options one by one:

Don’t change scope. Not allowing scope to change is fundamentally a waterfall strategy even if employed for agile teams and can have the same side effects in agile as we see in waterfall run projects. First, the team can end up developing a product that does not meet the needs of the customer. Second, if the scope change is initiated by the technical team, avoiding it may lead to the creation of technical debt that may have a direct impact on the quality of the product longer-term or future velocity of the team.

Work extra hard/more hours. A team can be motivated along a milestone or goal to do what it takes but this strategy is not very repeatable and does not last very long before it starts to take a toll.

Pull more developers from other teams or projects. This strategy also is not very repeatable as continuously doing this is going to have an impact on other ongoing projects or company milestones. Plus in an agile environment, the constitution of the team should ideally be fixed for long periods to achieve stable velocities.

None of these options tend to align the stakeholders in a common direction and this has an effect on how the team collaborates in the long run. That is the reason why we started to explore creating additional options that we could use as we describe below:

An objective approach to defining scope

What if we changed the way scope was managed to be more objective and rules based? Our hypothesis was that an objective approach should be well received by the teams although it may lead to a relatively smaller scope on average. This was because we felt that having rules would make it slightly harder for stakeholders to push more scope that usual. One way to compensate for the smaller scope was to release more frequently to production — an idea every stakeholder supported. Thus was born our monthly release train schedule which has become an integral part of our scope management process. We will explain more on that in a bit.

Our starting point to define a rules based approach to managing scope was the scrum DONE criteria —Only features that met the DONE criteria (as defined by the team), would be included in scope. To rephrase this rule so it is not as subtle:

Instead of predefining the scope of a release before development even starts, the scope would be defined as an aggregation of all development that meets the DONE criteria. The dates on which we evaluate what development meets the DONE criteria for production releases are fixed (as part of our release train schedule).

In other words, changes that do not meet the DONE criteria are kept off the mainline code (e.g using branch by abstraction or feature branches). Teams are expected to ensure that code committed to the mainline is releasable to production with low risk. Having a functioning CI pipeline with focus on test automation is a key enabler to manage this risk.

Implementing the new approach

In the new approach, identification of scope is a very simple task which can now be automated by scraping mainline code commits on a schedule as per our release train and then reconciling those with tickets in the team backlogs. We would leave the harrowing details of scraping code to another article.

So far, our experience with the new approach is in line with proving our hypothesis correct. We are on the fifth release in our monthly release train. Release management has become a relatively quick and simple task (compared to lengthy and frustrating negotiations back and forth) and the teams focus now on increasing their velocity to increase the units of output each sprint.

By no means, we are suggesting that this option is a panacea for the problems we face managing scope effectively. However, compared to the other options for managing scope, it allows for some significant advantages:

• Our teams are more agile. Reconsideration of scope is key to being agile, building a product that is aligned with the needs of the stakeholders and creating the least amount of technical debt.
• Increased frequency of releases without sacrificing quality or creating stress/overwork. Preplanned scope is typically accompanied by behavior that leads to the buildup of stress in teams or causes overwork/burnout.
• Balancing feature development with the removal of technical debt. Teams can focus working on prioritized backlog over constantly being bogged down to deliver feature lists committed ahead of time to a customer.
• Encouraging test automation and continuous integration. Not having these enablers makes it quite risky to ensure code is stable and releasable before committing to mainline.

We are still collecting data and tweaking this approach. Perhaps we will follow up with more interesting experiences of success or failure or changes we ended up making. Meanwhile, do feel free to ping us with questions or give us tips and suggestions for improvement!