Scope creep hovers over every software development project. It can happen to any individual and any team, and like any other agile practice, no two teams manage scope creep in quite the same way. Understanding how to identify scope creep, how it can impact your work, and what to do about it is half the battle of avoiding unhelpful scope creep (hot take: it’s not always a bad thing!)
What is scope creep?
Scope creep occurs when a project grows beyond its original ambition while in progress (i.e., work added that was not part of an original sprint, epic, or even release). Scope creep can happen for a number of reasons, including:
- Market conditions change and require a different feature set
- User feedback reveals that a feature needs to work differently
- Implementation complexity or unexpected dependencies unfold as teams work
- A poor understanding of the original project’s scope causes continuous growth (this should sound very familiar)
When it’s not managed properly and handled transparently, scope creep can sideline any team – and teams at Atlassian are no exception. We went straight to the horse’s mouth to learn how two of our teams deal with this threat, interviewing development leads on two teams: the Jira Agile team and the Fusion team (which oversees Jira Software’s integrations with Atlassian’s developer tools). Even though these teams work together often, we were surprised to learn how differently they manage scope creep.
How to identify scope creep
Scope creep rarely materializes out of thin air, but identifying it early on is key. Why? Because it can delay a release or, even worse, it can introduce unnecessary code and risk to software.
Development manager Michael Tokar says that during a sprint – the Jira Agile team works in two-week sprints – his team likes to visualize their work by using AtlasBoards, gadgets, and burndown charts. He has AtlasBoards set up on TVs around his team with the Sprint Health widget front and center. The Sprint Health widget shows bars that simply SUM(Estimates) groupings of status/columns. He has his widget set up with a condensed view to show a progress bar with time elapsed and scope completed. This means that scope change is visible for Michael and the entire team during a sprint.
Michael also recommends setting up the Agile Sprint Health Gadget and the Agile Sprint Burndown Gadget on your Jira dashboard. For those not familiar, burndown charts depict the actual versus estimated amount of work to be done in a sprint. This graph helps a development manager like Michael see how his team delivers work during a sprint and the likelihood of reaching the sprint goal. When the burndown doesn’t follow the guideline, it’s a strong indication that something has gone awry, and scope creep is a likely culprit. Since all Jira Agile reports show data in real-time, Michael is able to see blips on a graph or percentage changes without having to do much digging.
For the Fusion team, identifying scope creep depends on the type of scope change. Team lead Bruce Templeton says that real scope creep – where the product owner says “Don’t ship until you do X, Y, and Z” – is the most straightforward kind, and the easiest to identify. He creates stories in Portfolio for Jira and the team assigns estimates to these stories to see the impact. On the other hand, scope caused by unforseen variables – e.g. an API changed, or the the feature needs to fit into a different page layout – is found by integrating early and continuously with extensive Bamboo builds.
Because the Fusion team is dependent on other teams, Bruce also uses “scrum-of-scrum” meetings – multi-team stand-ups with several scrum teams working on a large project – to identify scope change. Scrum-of-scrums opens doors for knowledge-sharing and surfaces important issues, such as scope creep, early on.
How to manage the impact of scope creep
With reports, gadgets, and tools like Jira Portfolio, it’s pretty easy to see when scope creep, well, creeps into a sprint’s workload. The next step, managing the impact of scope creep, is a bit more complicated. As Michael describes it, dealing with scope creep is “not just about mitigating, it’s about understanding.”
Change in scope can manifest in many ways, but in any scenario, the team lead should communicate with the product manager before the scope is added or just after. As Michael puts it, team leads care most about “how much we committed to and got done” during a sprint. So after a new story is added, it is brought to the attention of the team at the next standup – particularly if it’s high priority. For the Jira Agile team, part of understanding the impact of scope creep, is communicating change early on between team members, which triggers conversations around estimation and the trade-offs of adding new work.
Bruce, on the other hand, is immediately interested in how scope change affects when his team can deliver, so he uses Portfolio for Jira to play with “what-if scenarios.” Bruce ensures all his team’s data from Jira Software is rolled up into Portfolio for Jira, so he can model potential outcomes and see the impact of scope changes on the Fusion team’s roadmap.
This scenario planning is generally done with both Bruce and the Fusion team’s product manager. They move around variables like release dates, scope, and resources (i.e., people) – Bruce calls this “playing with the levers.” They play until they find the right balance or a good compromise. When scope creep happens, it’s important to have all options on the table so you can make data-driven decisions.
How to respond to scope creep
So the scope change has been identified, and you understand where it came from. But now decisions need to be made. Do you accept the scope changes and release later? Get more resources? Shave off some initial requirements? What’s a team to do?!
The Jira Software team uses the Epic Burndown and Release Burndown charts, accessed in the reports view on the sidebar, to look at the bigger picture of a project to manage scope creep. An Epic Burndown chart shows the team’s progress towards finishing an epic, broken down by sprints. It also shows a work forecast of how many sprints remain before the epic will be complete. Most importantly in the context of scope creep, this chart highlights when work is added and how much (a Release Burndown chart highlights the same information, but at the release level). A team might have had the best intentions to finish an epic in 10 sprints, but after six sprints, the Epic Burndown may show that the remaining workload is another six sprints.
Unlike the Jira Agile team, the Fusion team relies less on burndown charts and more on what-if scenario planning using Portfolio for Jira, because “war-gaming it” gives full visibility into the potential options and impacts of scope change. Even though Portfolio for Jira’s what-if scenarios and Jira Software’s burndown charts give stakeholders the data points to empower teams to make decisions, it’s up to the team to take action and make tough (oh-so-tough!) decisions.
Based on lean agile principles, a team might agree that they want to get their latest feature out as soon as possible, so a new minimal viable product (MVP) is agreed upon. This way, the new feature is in the hands of customers faster than if the team added more sprints to that epic. A trade-off like this means that the feature, or release, will not be what the team thought they were going to deliver at the beginning of a project. And that’s ok. Adjusting mindfully is what agile is all about.
Once a decision has been made, a team lead like Bruce can re-order the backlog (stories, epics or initiatives) in Portfolio for Jira or Jira Software. In the case of Portfolio for Jira, the new backlog will automatically update the roadmap based on the new release times. Using real-time data is what makes re-organizing the workload achievable instead of death sentence for your weekend.
How to communicate the effects of scope creep
Keeping everyone in the loop once decisions have been made is the final step when dealing with scope creep. Adding scope can hurt a team’s morale, because on paper it might look like the team did not get accomplish what they set out to do. It’s important for the entire team to understand why scope was added and what implications it has on the future of a sprint, epic, release, and project.
For the Jira Software team, conversations around adding scope happen between the team lead and product manager, while Michael, the development manager, keeps a close eye on work in progress through reports. Scope creep is also a large topic of conversation during the Jira Software team’s retrospective meeting. These meetings get everyone in a room to understand decisions made, or the new game plan if there is one, and what to expect in the next sprint. Everyone on the Jira Software team is made aware of scope change as early and often as possible.
Bruce finds that using Portfolio for Jira makes communicating the effects of scope change quite liberating as the estimates are data-based and not a back-of-the-napkin calculation. As he knows all of the available options in Portfolio for Jira, it’s a great way to communicate openly with stakeholders. Also, the Fusion roadmap is accessible to the whole team, so everyone can stay on the same page when it comes to deliverables and release dates.
Scope creep is inevitable, and dealing with it is a necessary part of almost any role. Share what you’ve learned from this rundown on your social network of choice – your fellow Jira users around the world will thank you!