Scope creep and creepy stories?

Question

In Agile, Scrum, in which situations is used the word "creep" ? Can I tag or define my stories added in an active sprint as creep?

In my current company, we work using Agile and Scrum methodologies. We try to respect the best practices but we also modified the method to fit our needs as recommended by Scrum itself. There are some things I do not agree to do but my product owner gives me no choice. My product owner sometimes adds urgent stories in active sprints. Our business requires it.

I want to be able to identify these stories that "break" the sprint. I wanted to tag them as "breaking stories" then I discovered the usage of the word "creep" and scope creep to identify all these features that increase the scope of a project during the project.

It seems that "scope creep" is used to identify all these requirements added to the scope, increasing the scope but that can be avoided. In my situation the added stories are very important for us. I cannot say no, I just can tell my product owner his management is bad and he should tell us the story in time.

Is there a way or a terminology that is given to such stories, requests, features? Is "creep" also ok. My objective is to use a good terminology for all members of the teams and my future reports. I must bring the idea, in my company, we have a problem with these stories. I must tag them, I must name them, I must evaluate them in my reports, I need to come with a good name and report to alert on the risk.

I don't want to open a debate here, I have the feeling something exists and some people already have the answer... You can just confirm that "creepy story" is the terminology.

Thank you,

I like the word but in my case the stories added by my business are not new features we can avoid. I have to say, the request are really urgent changes requested by our clients that require to be added at the last moment. For real, I cannot reject these stories.

Answer 1

Scope creep is uncontrolled change in the scope of work, with other project constraints staying in place as initially estimated. It tends to be a concept that mostly applies to predictive styles of development who rely on an initial plan that then is assumed can be executed with no changes.

So in predictive approaches, changes are seen as bad, because they deviate from the plan. Any change needs to be considered carefully and approved before any work is undertaken to address it. But unlike some big changes that are usually visible, explicitly addressed, and approved, there are also many changes that can creep in for many reasons, and so the term scope creep. If the change in scope is agreed and approved, then that's just a scope change, but if it bypasses those steps, it's an uncontrolled scope change.

Agile methods embrace change. It's one of the values, of responding to change over following a plan. Change is the only constant in software development. Agile methods just recognize that. This is why you work in short iterations, to accommodate change that will be needed to something you built, when you see that what you built is not yet sufficient. No point in pretending you knew exactly what you needed upfront.

So because of this, scope creep is something that tends to occur less within Agile, simply because the changes are part of the way you work.

But then comes Scrum.

Scrum says that you work in sprints of fixed time length, and each sprint has a goal, and that the work to fulfil that goal is planned at the beginning of the sprint, and that scope of work is then fixed. Any changes discovered during the active sprint should wait for the next sprint to be planned. You do not keep your planned sprint as it is and add the extra work on top of it and still carry on as if nothing changed since you planned the active sprint. If this happens, then you could then call this scope creep.

If the work is urgent and can't wait, you either cancel the current sprint and focus on the emergency, or throw something out from the sprint and replace it with the new work, assuming you can still keep the goal of the sprint to some extent. But then that's quite visible to everyone and a decision has explicitly been taken to do the work. So not really a scope creep. But it is a scope change, because you planned a different scope for that sprint initially.

If this happens once in a blue moon, that's fine. But if it's constantly happening and you either need to re-plan your sprints or cancel them, then you should analyze what's going on and decide how to proceed next.

Maybe the PO needs more training or help in recognizing what is urgent and what can wait for the next sprint, or maybe your sprints are too long. Or maybe Scrum is not the proper method to use if you constantly need to react to new work or priorities (and Kanban might be better suited).

So that's what you need to do. As Agile says: inspect and adapt.

While you do that, to gather more information, you can track the changes. You can use burn-up charts to show the scope change. You can have reports that show the velocity of the team and the +SPs that were added to the sprint. Or the -SPs/+SPs when you removed stories and replaced them with something else. And also capture canceled sprints with the reason behind the decision. Or keep track of the stories themselves and tag them as "scope change" or "inserted in sprint" in your work tracking system for later evaluation. And if you see a pattern, analyze it and get to the root cause.

And please don't call things "creepy stories". Just call them by what they are: "scope change".

Answer 2

TL;DR

"Creepy stories" are not going to be understood by anyone outside your company as anything other than scary fairy tales or novels. This is not a term of art within project management or Scrum, nor does it fit typical English language usage.

If you just want a better explanation of why "creepy stories" or marking things as "creepy" is a poorly-chosen adjective, you might ask on English Language & Usage Stack Exchange or English Language Learners Stack Exchange depending on what kind of language-oriented answer you want. Here, you'll get a project management perspective.

From a Scrum framework perspective, the correct term is "scope creep." In Scrum, changes to scope are always permitted at framework inflection points, and can sometimes be absorbed within a Sprint so long as the changes don't endanger the Sprint Goal. However, "scope creep" in the sense of ever-expanding changes to the scope or significantly moving the objective defined for an iteration should never happen inside an active Sprint.

Analysis and Recommendations

The 2020 Scrum Guide makes a statement in relation to the Product Goal, but it's applicable to the Sprint Goal too.

[The Scrum Team] must fulfill (or abandon) one objective before taking on the next.

Regarding the Sprint Goal, the current edition of the Scrum Guide specifically says (although not in such a nicely-ordered fashion) that:

1. The Sprint Goal is the single objective for the Sprint.

2. The Sprint Goal is created during the Sprint Planning event[.]

3. The Sprint Goal must be finalized prior to the end of Sprint Planning.

4. [If planned work changes then the Developers] collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal.

5. A Sprint could be cancelled if the Sprint Goal becomes obsolete.

6. Only the Product Owner has the authority to cancel the Sprint.

Think about it this way. The Sprint Goal is a stepping stone towards a Product Goal, but if the goals change then the potentially-shippable Increment(s) may no longer have value. If value can be salvaged by:

• changing the scope of work items within the time remaining for the current Sprint,
• can be re-planned without invalidating the current Sprint Goal, and
• the refined Increment(s) that make up the Sprint Goal can still be delivered within the current Sprint

then the Developers can abandon irrelevant work in progress and collaborate with the Product Owner on updating or rebuilding the Sprint Backlog to fit the scope changes.

However, if the entire plan for the Sprint is invalidated by proposed changes, and if there is truly value in abandoning the current objectives, then this realignment must be treated as a visible cost to the project. This creates an escape hatch in the Scrum framework that allows the Scrum Team to create a new plan from scratch when necessary. Note that the framework does this while avoiding "invisible work" by making the cost of change outside of the framework's routine cadence—a cadence which already contains frequent inspect-and-adapt inflection points—fully visible to the team and its stakeholders by requiring the Product Owner to call for an early termination because specific changes are so essential that they justify the cost of abandoning all current work-in-progress in order to create an entirely new Sprint Backlog to meet an entirely new Sprint Goal.

Agility requires adapting to change, but Scrum Theory requires a predictable cadence and transparency. CodeGnome's Law of Transparency℠ also states "No invisible work, ever!" As a result, scope change may be possible within a Sprint, but scope creep indicates a lack of transparency, often involves invisible work, and often undermines the cadence of predictable events that Scrum is meant to deliver. So, Scrum enables you to embrace change while rejecting scope creep.

Early termination is essentially the "nuclear option" in Scrum. That's why it's done so rarely, and never without due diligence and careful consideration of other options within the framework—including stakeholder education about the importance of cadence, maintaining a cohesive goal, and respecting time boxes in Scrum whenever practical. There are always edge cases where immediate change is justified, though, which is why this option exists. If you must, then use it with care; it makes the expense of unpredictable change visible and exposes the process disruption it creates.

When required by senior leadership, though, you must push that big red button! That's what it's there for. If leadership routinely chooses to push the nuclear button over trivial things and won't collaborate with the Scrum Team to avoid the necessity...well, they get to keep the radioactive fallout.

See Also

• How can we handle urgent work items defined by leadership at the end of a Sprint?
• Differentiating between minor and drastic changes.
• Who decides if something should NOT be injected into a Sprint?

Answer 3

Scope creep means uncontrolled change. That doesn't seem to apply to your situation because the PO approved the change.

Adding new stories that impact the sprint goal may be an indication that sprints are too long. As a general rule, if your sprint is longer than 1 week then consider shortening it. If longer than 2 weeks then you have a very strong case for a shorter sprint. Shorter sprints are easier to predict and less prone to change.

If you have to live with changes then one thing you may want to do is report the points value of the originally planned stories completed alongside the overall velocity. Be as transparent as possible and the team can then take any shortfall into consideration when planning future sprints.

Answer 4

In Agile and Scrum methodologies, the term "creep" is commonly used to refer to scope creep or feature creep. It refers to the gradual expansion or addition of requirements, features, or tasks to a project beyond what was initially agreed upon or planned. Scope creep can occur when there are frequent changes in requirements, unclear project goals, or inadequate project management.

In the context of user stories, it is not typical to tag or define stories added to an active sprint as "creep." User stories are typically planned and committed to during the sprint planning session, and any changes or additions to the sprint backlog should ideally go through the proper prioritization and planning process.

If there are new requirements that arise during the sprint, it is recommended to have a conversation with the Product Owner and the development team to evaluate the impact and determine the best course of action. It may involve removing an existing user story from the sprint backlog to accommodate the new one, or deferring the new story to a future sprint.

It's important to note that scope creep can have negative implications on the team's ability to deliver on time and within the sprint's capacity. Therefore, it is generally advisable to manage changes and additions to the sprint backlog carefully and ensure that they align with the team's capacity and the sprint goals.

Answer 5

I agree with most answers but it seems that the question itself is addressing the symptom, not the disease. You mention you'd like to identify the items that are scope creep. That's fine.

But why do you want to do it?

This question is where you should focus, because depending on the answer you can have different approaches, most already explained by other answers:

Scenario 1: We're not able to deliver all the stories we planned

You might be missing a Sprint Goal. Follow Todd's answer.

Scenario 2: Our sprint Goal takes more time to deliver than planned

You might need to adjust what your Sprint Goal is. Follow nvogel's answer.

Scenario 3: This is just business as usual but I want to work better

You might need to coach more the PM (if there's support from senior management) or explore other frameworks like Kanban, although you'd be likely simply masking the problem. Follow Bogdan's answer.