The Problem with Scope Creep in an Agile Shop

Scope creep happens little by little, and then all at once. A story point here. An extra feature there. Innocently, you ask, “Can’t you just add this one teensy thing?” and then boom, your timeline is shot, your budgets are busted, and your backlog is straining at the seams. Throw resource planning out the door.

Scope creep is a huge risk factor to a project going off the rails. It’s also diabolically difficult to measure for two big reasons, both tied to Agile. Agile resists absolute scope measurement at the start of a project because Agile knows that no human or team of humans can possibly flesh out a project enough at the beginning to provide anything like a real estimate, and that effort to do so is both a waste of time and an exercise in aspirational thinking. Agile teams can provide high-level estimates, which are good, but which don’t even touch real scope. And then, there’s the problem of backlog grooming. During backlog grooming, the team provided details to some stories, breaks other stories into smaller component parts, adds stories to epics, and estimates stories by assigning point values. What this means is that from a metrics point of view every project will start smaller than it ends. Backlog grooming looks like scope creep.

Jira to the Rescue

Jira comes with some great out-of-the box reporting that you can use to look at scope creep.

1. Version Report: The Version Report overlays the total story points with the number of unestimated stories. (Total story points is shown in the gray area of the graph, while unestimated stories are shown by the red line.) As the red line trends down, the gray area will increase. Any additional stories added (but not estimated) will show in the red line, so if there’s a big spike in the red line, or a large sudden increase in the gray area, you can assume there’s some sort of activity happening with scope. The Version Report is good, but not great because you can’t divorce scope creep from normal sprint activity.
2. Epic Burndown Report: This report does a fantastic job at showing how many points were added to a particular epic. This is good for digging into a single epic, but, again, you’d expect that during the course of a sprint the stories will be getting fleshed out and new stories / points will be added.
3. Cumulative Flow Diagram: In my humble opinion, the Flow Diagram is the prettiest of the Jira charts. It shows the total volume stories for the project, and overlays the to-do status with the done. At a glance, it shows an increase in stories over time, with a gradual chipping away at the stories that had been completed. Looking at the top line, I can see when new stories were added, and can identify spikes in new stories. Spikes might mean scope creep.

The Product Manager Gut Check

Reporting is attractive, because it yields real numbers. But product managers have other ways of making sure the project is still in scope.

1. Pre-Jira backlog builder: Every product manager has some sort of pre-Jira feature list kicking around on the hard drive. The list might or might not be used to build out Jira, but it’s what the product manager used to create that first stab at Jira. You can compare the epics / stories in the backlog to this first pass to see whether new features have been added to the project. If they have, you know that scope hasn’t been managed correctly.
2. Icebox versions: Metal Toad projects get a non-release version called Icebox. We use Icebox to store great ideas that come up during the project. Icebox isn’t deep freeze. It’s dinner ready to go. If we have time, we can add Icebox issues to the project. If we don’t have time, we present the Icebox to the client as an output of the project itself. Other organizations / product managers have other ways of handling this same thing. It might be a placeholder line, which an “above / below the line” kind of prioritization. Or it might be the very very very last page of the 357-issues-long issue list, which includes things you’ll never get to. The important thing is that there’s a storage bucket for ideas that you choose not to build. If there’s no storage bucket, you’re either losing these great ideas, or you’re building them all into the project, which is the definition of scope creep.

Gut Check…

Finally, there is the gut check. Cruise the bullpen and ask the developers actually working on the project. If they say, “Yeah, we’re doing some things I didn’t think we’d be doing,” you’ve probably got some scope creep on your hands.