---
title: What 'Scope Creep' Actually Looks Like Inside a Refinement Session
description: Scope creep often enters products through refinement sessions. Learn why additions feel justified in the moment and how to spot the warning signs early.
image: https://weareaffective.com/hubfs/learning-centre-images/what-scope-creep-actually-looks-like-inside-a-refinement-session.webp
---

[Skip to content](https://weareaffective.com/learning-centre/what-scope-creep-actually-looks-like-inside-a-refinement-session#main-content)

[![we\_are\_affective\_logo\_200](https://weareaffective.com/hs-fs/hubfs/we_are_affective_logo_200.png?width=175&height=48&name=we_are_affective_logo_200.png "we_are_affective_logo_200")](https://weareaffective.com)

- [Home](https://weareaffective.com)
- About Us 
  
    - [Our Story](https://weareaffective.com/about)
    - [How We Work](https://weareaffective.com/how-we-work)
- Our Services 
  
    - [App Planning & Strategy](https://weareaffective.com/app-planning-strategy)
    - [App Design](https://weareaffective.com/app-design-agency)
    - [App UX Design](https://weareaffective.com/app-ux-design)
    - [App UI Design](https://weareaffective.com/app-ui-design)
    - [App Technical Architecture](https://weareaffective.com/app-architecture)
    - [Existing App Audits](https://weareaffective.com/app-audit)
- [Case Studies](https://weareaffective.com/case-studies)
- [Pricing](https://weareaffective.com/pricing)
- [Learning Centre](https://weareaffective.com/learning-centre)

- [Get Started](https://weareaffective.com/get-started)

Expert Guide Series

# What 'Scope Creep' Actually Looks Like Inside a Refinement Session

 Table of Contents

On a [sports club app project we ran](https://weareaffective.com/learning-centre/what-scope-creep-actually-costs-a-sports-club-app-that-spent-twelve-months-growi), every refinement session made the product bigger. The sessions existed to do the opposite. We would open up a feature, break it into parts, and look for the smallest version that still did the job. Then one of the founders would say that of course it also needed to handle this, and of course it needed to cover that, and by the time we closed the laptop the specification had grown.

> We ended up with a bigger product at the end, the complete opposite of what you should have.

Nothing about those sessions looked like a problem while they were happening. The conversation was warm. Everyone was engaged. People were thinking hard about the product, which is what you want from the people paying for it.

Scope creep gets written about as if it arrives in a change request, signed and dated, with a cost attached. In practice it arrives in a sentence beginning with "of course", from someone who believes they are clarifying rather than adding. This piece is about what that looks like in the room, why it is so hard to stop, and what we do differently now.

## What a Refinement Session Is Supposed to Do

A refinement session takes a feature that exists as a sentence and turns it into something a developer can build, and it sits at the heart of any solid [app planning and strategy](https://weareaffective.com/app-planning-strategy) process. You start with "members can pay their subs" and you finish with a known set of screens, states, rules and edge cases. The useful part of that work is subtraction. You are deciding what the first version does not do.

Done well, the output of a session is smaller than the input. We worked with a property developer on a concierge app for high-rise buildings, and they came to us with a budget and a fixed idea of the product, wanting us to validate it. We persuaded them into a [proper discovery phase with focus groups](https://weareaffective.com/learning-centre/how-to-scope-a-pre-build-research-phase-when-the-budget-is-already-signed-off-fo) and user workshops first. What we found was that the product needed to be far simpler than they had pictured. Features came out. The build cost less.

Refinement also sets the definition of done, which turns out to be rarer than it sounds. [Geneca](https://www.geneca.com/why-up-to-75-of-software-projects-will-fail/) report that up to 77% of people working on software projects say they do not know how to tell when their project is finished, in their own self-reported survey data. A session that ends without anyone writing down what is out has not produced a definition of done. It has produced a longer list.

## The Pattern: Sessions That Shrink Nothing

The sports club app was well funded. It was built to handle finances, games, schedules and players across a range of sports, and the client pushed back on our release advice from the very start. They did not want to launch with one sport. They did not want one platform first. No MVP, no staged release, nothing live until everything was ready.

That decision set the conditions for everything that followed. When there is no launch date that forces a choice, nothing in a refinement session has to be cut. Every idea can be true at once, because the product is a document rather than a thing people use. So the sessions turned into a place to think out loud about the finished vision, and the specification absorbed each new thought.

We would go in to refine a feature down and come out with it broader than when we started. The founders were adamant the additions belonged in the product specs, and they said so with real conviction, because to them the additions were obvious. We warned them early that the budget was going to get wildly out of control and that they risked running out of money before anything reached the store. Those warnings were noted. The features kept coming.

## Start your app project the *right* way

We deliver the complete blueprint before a line of code is written. User research, psychology-driven design and full technical specifications. You choose who builds it.

[See how we work](https://weareaffective.com/how-we-work) [Get started](https://weareaffective.com/get-started)

No commitment

## 'Of Course It Needs To Do This': How Additions Get Justified

"Of course it needs to" is a strong phrase because it does two jobs at once. It introduces something new and it tells everyone the thing was never new. Argue with it and you look like you have not been paying attention. Agree with it and the product grows by a feature nobody costed.

On the sports club app, both founders used that framing constantly, and neither was being difficult. They lived in the world the app was for. The additions genuinely felt implied to them, in the way that a door feels implied by a house.

> "Of course it needs to do this" is a feeling about the feature, dressed up as a requirement nobody can question.

We saw a related version of this on an auction game. Engagement was sliding, and the client wanted to keep adding new features to pull people back in, each one obviously necessary in the moment. We looked at where the drop was actually happening and focused on the core journey of someone arriving and playing the game, rather than the ancillary features. The pull towards addition is strongest exactly when the product is struggling, which is when it does the most damage.

## Why Removing a Feature Is Harder Than Adding One

Adding is a single act with one author. Removing asks several people to agree that work already paid for, already designed, or already imagined in detail, will not exist. The feeling of losing something you already count as yours is heavier than the feeling of gaining something equivalent, and a feature described in a spec is already owned by somebody.

The two moves also face completely different tests inside a room.

| Move | What it needs to pass | How it feels |
| --- | --- | --- |
| Adding a feature | One person saying "of course" | Generous, ambitious |
| Removing a feature | Agreement from everyone attached to it | Negative, like a cut to the vision |
| Deferring a feature | A date and an owner | Safe, often the only cut that lands |

Give every cut a destination. "Out of version one, revisit after launch" lands where "we are dropping it" starts an argument.

On the concierge app, removal worked because the evidence arrived before the attachment hardened. The focus groups told us what residents wanted, so dropping features stopped being our opinion against the client's and became a shared reading of what the building's people had said. Nobody had to lose.

## Recency Bias and the Tyranny of the Last Thing Said

The last five minutes of a session carry more weight than they have earned. People are tired, the agenda is done, and someone raises one more thought. It goes into the notes with the same status as the decisions that took forty minutes to reach, and by the next session it is simply part of the spec.

The same pull reopens things that were already settled. We identified a pattern across two projects, a fitness and wellness app and a [grassroots football product](https://weareaffective.com/learning-centre/what-a-grassroots-football-club-learned-about-scope-expansion-in-refinement-sess), where founders with strong personal conviction kept rolling back sign-offs to request further changes. A decision signed off in March got reopened in May because of something said in a meeting the week before. Both projects spent their entire budget in design and build. Neither reached a full live version.

Two habits hold against this. Write decisions down inside the session, in the client's own words, and read them back before anyone leaves. Then treat anything raised in the final ten minutes as a candidate for the next session rather than a decision from this one. It sounds bureaucratic. It saves the thing that the room agreed when it was fresh, and it gives the late idea a fair hearing instead of a free pass.

## Who Isn't in the Room: Absent Stakeholders and Unowned Trade-offs

Scope grows fastest when the people who carry the consequences are elsewhere. The developer who has to build the edge case, the support person who answers the emails, the user who has to understand the screen. None of them are there to say what an addition costs, so the addition costs nothing in the moment.

We saw where that leads on a [dating app built around verified profiles](https://weareaffective.com/learning-centre/what-mobile-app-design-and-development-services-does-your-business-actually-need) and keeping bots out. The client chose to skip discovery on the messaging side and put everything into the onboarding process. What got built was a generic messaging feature, and it allowed automated and fake messages, the exact behaviour the verification work existed to prevent. Nobody in the messaging conversation was holding the promise the onboarding had made.

Gaps like that account for a lot of rework. One study on [arXiv, 2020](https://arxiv.org/abs/2007.01761) traced 78% of requirements-related rework to avoidable gaps in shared understanding between stakeholders and development teams.

So we now ask, out loud, who is affected by each change and whether anyone present speaks for them. If the answer is nobody, the change waits until someone does.

## Founder Proximity and the Conviction Problem

Decision-making on the sports club app sat with two co-founders who already worked and lived in the environment the app served. The app was the business, rather than a marketing channel for it, so they were close to it professionally and emotionally. Both were strong willed, both contributed to the constant push for more, and each of them believed their additions were already implied by what had been agreed.

Proximity is useful right up to the point where it replaces evidence. We worked with another founder who had deep industry experience and fixed views about how the product should work. The research became a box-ticking exercise. We showed compelling evidence that large numbers of their potential users did not want particular features and preferred something else, and they did not move at all. We walked away from the engagement. They launched roughly a year later, close to their original plan, and as far as we can tell it went nowhere.

> A founder close enough to feel the problem daily is often close enough to stop hearing the research.

Conviction builds products. It also makes refinement sessions one-sided, because a founder's instinct arrives already sounding like a conclusion.

## The Hidden Scope Nobody Logs: Technical Constraints and Workarounds

Not all scope arrives as a feature. Some of it arrives as a constraint that forces a worse way of building the same thing, and that never appears on a feature list, so nobody treats it as growth.

On an [alcohol buying and selling platform](https://weareaffective.com/learning-centre/the-hidden-complexity-of-delivery-apps-what-every-business-owner-should-know), we were pushed into embedding web elements rather than building a proper API layer. The product did exactly what it said it did. Underneath, every screen touching those embeds took longer to build, longer to test and longer to fix. We put the uplift at around 20% more work across the whole length of the project. The client wanted the budget to stay where it was, so we dropped features towards the end to pay for it.

Log technical workarounds in the same place as feature changes. A constraint that adds a fifth to the build is a scope change, whatever it is called.

That is the part of scope that goes unrecorded. The features were visible and the cut at the end was visible, and the cause sat in a decision about integration made months before, which nobody had written down as a cost. Ask what each constraint adds in percentage terms, and get it into the same record as everything else.

## What Scope Creep Costs in Money, Time and Coherence

The money is the easy part to see. The dating app rewrite came to roughly £15,000 of extra budget and about two months of extra work, because the messaging section had to be rebuilt to match the rest of the product.

| Project | What happened | What it cost |
| --- | --- | --- |
| Dating app, verified profiles | Discovery skipped on messaging | About £15,000 and two months of rework |
| Sports club app | Feature after feature, no staged launch | Entire budget, nothing published to the store |
| Alcohol platform | Embedded web instead of an API layer | Around 20% more work, features dropped late |
| Grassroots football product | Research findings set aside | Budget spent in design and build, no live product |

The coherence cost is quieter and harder to repair. A product that has grown by accretion stops making one argument to the person using it. On the dating app, all the emphasis we put into onboarding, validation and verification did not stack up with the messaging side, so the product told users two different stories about how safe it was.

Then there is the cost of never shipping. The sports club app ended with the budget gone, nothing on the app store, and the client and ourselves parting company. Every pound of that was spent on real [design and real engineering](https://weareaffective.com/learning-centre/why-your-social-media-app-needs-more-than-just-pretty-design). None of it reached a user.

## Early Warning Signs in the First Fifteen Minutes

You can usually tell inside a quarter of an hour whether a session is going to shrink the product or grow it. The signals are small and they are social rather than technical.

- Someone opens with "just a quick thing before we start".
- A new attendee is in the meeting and nobody has said what they are there to decide.
- The word "obviously" appears in the first ten minutes.
- A decision from the last session gets described as "where we had got to", rather than as agreed.
- Nobody has named anything that is out of scope.

That last one does most of the damage. A session where the only live question is what goes in has already chosen its direction.

The slower warning signs sit at project level, and we flagged them early on both the fitness and wellness app and the grassroots football product. An excessive drive to perfect everything before launch. Sign-offs being rolled back for further changes. Decisions that take weeks when they should take days. We said where that trajectory led on both projects. Both got there anyway, with the budget spent and no full live product to show for it.

## Facilitation Choices That Actually Hold Scope

Holding scope is mostly about what the facilitator does in the first two minutes and the last two. Open by reading out what is already out of scope and why, so the session starts with a boundary rather than a blank page. Close by reading back every decision, including the ones where something was removed.

In between, the move that works best is the swap. When something new arrives, we ask which agreed item comes out to pay for it. That turns an addition into a choice with two sides, and the person proposing it has to weigh their idea against something they already wanted. Half the time the idea gets withdrawn without anyone having to say no.

Writing changes down as they happen matters more than it sounds. A Scope Management Tracker tool tested in a [Springer Nature, 2025](https://link.springer.com/chapter/10.1007/978-3-031-91235-1_27) conference paper reduced the frequency of scope changes by roughly 30% under its test conditions, which were specific to that tool and that study. The tool is less interesting than the behaviour behind it. Making each change visible, with a cost next to it, changes how freely people ask.

## Evidence as the Only Acceptable Reason to Add

A feature gets in because users showed us they need it. That is the whole test, and it holds the room better than any argument about budget, because it takes the decision away from whoever is most senior or most certain.

The concierge app is the clearest case of it working in our favour. The developer wanted a full building management utility and a community-building social tool at the same time, and those two goals pulled against each other. We ran focus groups with social housing tenants to understand what actually builds community, and what came back was familiarity. People knowing each other's names, their interests, their families, their pets. So we put the mundane building tasks into the app and designed the rest to push people towards face-to-face conversation instead of replacing it. Features we had planned were dropped, and nobody fought for them, because the tenants had already answered the question.

Bring [one page of research to every refinement session](https://weareaffective.com/learning-centre/research-findings-from-our-own-work-where-lifestyle-brand-reorder-flows-break-do). It gives the room something other than seniority to defer to.

Projects that are strong at drawing out requirements see fewer costly mid-project changes, by about 28% according to [plprojects](https://plprojects.co.uk/eliciting-requirements-from-stakeholders/), who do not name an original source for the figure.

## Making the Cut Decision Stick After the Session Ends

A cut agreed at four o'clock on Thursday lasts until someone remembers the feature fondly on Monday. The decision needs a record with enough detail that reopening it feels like a decision in itself.

1. Write the cut in the client's own words, in the session, on screen.
2. Record the reason next to it, with the evidence it rests on.
3. Name one person who owns the decision.
4. Circulate it within a day, while the discussion is still fresh.
5. Read the list of cuts aloud at the start of the next session.

Step five does the heavy work. Items that have been read out four times stop being candidates for quiet reinstatement.

Records alone will not save a project where the client has decided not to work with the process. We noted our warnings on the sports club app and the client kept adding anyway, which is the limit of what documentation does. What the record changes is the conversation six weeks later, when the budget is tight and somebody asks how the product got this big. The answer is written down, with dates, and the trade-offs are visible rather than disputed. Working with the process, and listening to the advice you paid for, is the part no template can replace.

## Conclusion

Scope creep in a refinement session does not look like someone demanding more. It looks like clarification, enthusiasm, and a founder who knows the subject better than anyone else in the room. The sports club app had funding, talent and two people who understood their market deeply, and it finished with the budget gone and nothing on the store, one obvious addition at a time.

The projects that went the other way had the same pressure applied in the opposite direction. The concierge app got simpler because tenants told us what mattered and we let that decide. The auction game improved when we put the core journey ahead of the ancillary features. In both cases somebody in the room was willing to say what the product was not going to do, and had evidence behind them when they said it.

So the practical question for your next session is small. Before anyone proposes anything, can you say out loud what is out of scope and why? If you cannot, the session will grow the product, however carefully it is run.

If you are heading into a build and want the refinement work to actually reduce what you are building, [let's talk about holding scope on your project](https://weareaffective.com/get-started).

## Frequently Asked Questions

What is a refinement session actually meant to achieve?

A refinement session takes a feature that exists as a single sentence and turns it into something a developer can build, with known screens, states, rules and edge cases. The valuable part of that work is subtraction, deciding what the first version will not do. Done well, the output should be smaller than the input.

How do I spot scope creep if it does not arrive as a formal change request?

It usually arrives in conversation, in a sentence that starts with "of course it also needs to...", from someone who genuinely believes they are clarifying rather than adding. The tell is not conflict, it is a warm, engaged session that ends with a longer specification than it started with. If your feature is broader on the way out than it was on the way in, that is scope creep.

Why is this kind of scope creep so hard to challenge in the room?

Because nothing about it looks like a problem while it is happening. The client is engaged, thinking hard about their own product, and the additions feel obvious and necessary to them rather than new. Pushing back can feel like you are being obstructive about something that sounds self-evidently right.

What role does the launch date play in keeping scope under control?

A real launch date forces choices, because something has to ship and therefore something has to be cut. Without one, every idea can be true at once, since the product is still a document rather than a thing people use. On the sports club project, the refusal to stage the release removed the one pressure that would have made subtraction necessary.

What does a proper definition of done look like?

It includes what is out of scope, written down, not just what is in. Geneca found that up to 77% of people working on software projects say they cannot tell when their project is finished, which suggests most teams never get there. If a session ends without anyone recording what has been excluded, you have produced a longer list, not a definition of done.

Can discovery work actually reduce scope rather than expand it?

Yes, and that is often the point. On a concierge app for a property developer, focus groups and user workshops showed the product needed to be far simpler than the client had pictured. Features came out of the scope and the build cost less than the budget they had already signed off.

Our client has already fixed the budget and the product idea. Is research still worth doing?

It is often most worth doing in exactly that situation, because a fixed idea that has not been tested is where the expensive mistakes live. Research can show that the real requirement is smaller than the assumed one, which protects the budget rather than consuming it. The property developer example started with a signed-off budget and a fixed idea, and research made the build cheaper.

What should I do differently in my next refinement session?

Open the session by stating that the goal is a smaller specification, so subtraction is the expected outcome rather than a negotiation. Capture every "of course it also needs" addition somewhere visible, but outside the first release, so it is acknowledged without being absorbed. Close by writing down explicitly what is out, and tie the feature to a launch date that makes the cut real.

## Related Articles

[![We Are Affective](https://weareaffective.com/hubfs/we_are_affective_logo_mark.svg)](https://weareaffective.com)

20-22 Wenlock Road  
London, N1 7GU  
United Kingdom

+44 20 4572 8062  
[hello@weareaffective.com](mailto:hello@weareaffective.com)

<https://linkedin.com/company/weareaffective> <https://instagram.com/weareaffective> <https://facebook.com/weareaffective>

Services

[App planning & strategy](https://weareaffective.com/app-planning-strategy) [App design](https://weareaffective.com/app-design-agency) [App UX design](https://weareaffective.com/app-ux-design) [App UI design](https://weareaffective.com/app-ui-design) [App technical architecture](https://weareaffective.com/app-architecture) [Existing app audits](https://weareaffective.com/app-audit)

Legal

[Privacy policy](https://app.termly.io/policy-viewer/policy.html?policyUUID=b8fa9921-7518-4fb5-8ddd-9dc7f5977ed2) [Terms](https://app.termly.io/policy-viewer/policy.html?policyUUID=8b6a6ad5-91bd-4176-a5f7-6d36b0398f70)

Case studies

[TravAI](https://weareaffective.com/case-studies/travai) [Meditech](https://weareaffective.com/case-studies/harley) [WorkingWeight](https://weareaffective.com/case-studies/workingweight) [SkinSync](https://weareaffective.com/case-studies/skinsync) [Three Lochs](https://weareaffective.com/case-studies/three-lochs) [Drift](https://weareaffective.com/case-studies/drift)

About us

[Our Story](https://weareaffective.com/about) [How We Work](https://weareaffective.com/how-we-work)

Guides

[Creating an app](https://weareaffective.com/how-to-create-an-app) [Building an MVP](https://weareaffective.com/building-an-mvp) [Cost and budgeting](https://weareaffective.com/app-development-cost) [App technology](https://weareaffective.com/app-development) [Planning and strategy](https://weareaffective.com/app-planning-strategy) [User research](https://weareaffective.com/app-user-research) [Onboarding design](https://weareaffective.com/app-onboarding-design) [User psychology](https://weareaffective.com/user-psychology-app-design) [Launch and growth](https://weareaffective.com/app-launch-growth)

 Copyright © 2026, weareaffective.com. All rights reserved.