Stealthy and unavoidable, scope creep hovers over every software development project. Like any other agile practice, no two teams manage scope creep the same and teams at Atlassian are no exception. So we decided to go straight to the horse’s mouth to learn how two of our teams deal with scope creep.
We interviewed development leads on two teams: the JIRA Agile team and the Fusion team – our Fusion team oversees JIRA and JIRA Agile integrations with Atlassian’s developer tools. Even though these teams work together often, we were surprised to learn how differently they manage scope creep. But before we get into their stories, let’s remind ourselves of what scope creep is and why it happens.
When scope starts to creep
Scope creep is when a project grows beyond it’s 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)
Keep in mind, scope creep is not necessarily a bad thing.
Scope creep can be a healthy indicator for an agile team as you keep iterating, learning, and reacting to external input.
But when it’s not managed properly or is transparently handled, it turns into a problem.
Whatever the cause, it is important to know how to (1) identify scope creep, (2) understand the impact, (3) make data-based decisions to adjust, and lastly (4) clearly communicate changes to the entire team.
1. How to identify scope creep
Scope creep rarely materializes out of thin air, but identifying it early on is key. Why? Because scope creep can delay a release, or worse: it can introduce unnecessary code and risk to software.
So how does the JIRA Agile team identify scope creep? Development manager Michael Tokar says that during a sprint – the JIRA Agile team works in two week sprints – his team loves AtlasBoards, gadgets, and burndown charts. He has AtlasBoards setup on TV’s 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.
Besides Atlasboards, 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, this is 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. Bruce Templeton, the team lead, says that real scope creep where the product owner says “Don’t ship until you do X, Y, and Z”, is the most straight-forward kind and easiest to identify. He creates stories in JIRA Portfolio 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.
2. How to understand 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.”
As we mentioned above, change in scope can range from adding a new story that is required in order to complete work you’ve already committed to. Or perhaps a specialist on your team who ran out of work during a sprint and needs more. And an even more common one is when the product manager has received an urgent request from a stakeholder. In all of these instances, the team lead is in talks with the product manager before the scope is added or just after.
As Michael puts it, team leads care most about “how much did we commit to and get done” during a sprint. So after a new story is added, it is brought to the attention of the team at the next stand-up – particularly if it’s high priority. Part of understanding the impact of scope creep, for the JIRA Agile team, 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 JIRA Portfolio to play with “what-if scenarios.” Bruce ensures all his team’s data from JIRA and JIRA Agile is rolled up into JIRA Portfolio, so he can model what-if scenarios 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 in which 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.
3. How to re-organize your workload based on scope creep
Ok: 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 Agile 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 shows 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 JIRA Portfolio, because “war-gaming it” gives full visibility into the potential options and impacts of scope change. Even though JIRA Portfolio’s what-if scenarios and JIRA Agile’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 JIRA Portfolio or JIRA Agile. In the case of JIRA Portfolio, 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.
4. 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 Agile 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 Agile 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 Agile team is made aware of scope change as early and often as possible.
Bruce finds that using JIRA Portfolio makes communicating the affects 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 JIRA Portfolio, 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
Scope creep is inevitable and dealing with it is necessary. We’ve shared some of the ways we deal with it at Atlassian, and now we’d love to see how you manage it, too. Share your scope creep tips and tricks in the comments. And if you’ve found this post useful, please share it on your social network of choice – your fellow JIRA users around the world will thank you! 
The post 4 essential how-tos for dealing with scope creep appeared first on Atlassian Blogs.