In the world of project management, improvements and features added to the original concept are expected. In fact, 52 percent of projects experience scope creep, according to a 2018 survey by the Project Management Institute.
To prevent scope creep, teams must over-communicate, Jeff Soto, technology director at Work & Co, said.
“When scope creep does happen, it’s important that your team and client fully understand feature prioritization,” Soto said. “Strong communication and trust between all project teams and stakeholders help facilitate the balancing act between delivering the best possible product and working within the limitations of timelines, resources and budget.”
What is Scope Creep?
Once all stakeholders are aware of a project’s priorities, project managers and software engineering teams can react to scope creep more effectively and agree on what may slide in and out of scope.
Other tips for managing scope creep include setting clear goals for projects and having trusted processes in place to try out new additions.
“Flexibility is so important in what we do,” Software Engineer Alexander Frankel said. He doesn’t operate under a “no-scope-creep” policy at Common, but rather sets expectations up front so the whole team can work toward the same deadline.
Additional helpful measures? Documentation, strong communication between project teams and stakeholders, and a sense of trust and transparency between directors and engineers.
How to Manage Scope Creep
- Perform thorough research for initial discovery phases
- Encourage complete transparency between project managers and developers
- Set clear goals and expectations at the beginning of each project
- Keep projects small with consistent and quick releases
- Always be communicating
Work & Co
Soto said the focus at digital agency Work & Co is on building and delivering the best user experiences and for companies through digital design. For example, they launched “Highlights” for Gatorade, an app that lets athletes capture and share their personal sports accomplishments. When working with brands, their model is a more hands-on approach with all parties putting equal time into product life cycles.
What proactive measures does your team take to limit or prevent scope creep, and who are the other stakeholders involved?
Our initial discovery phase on client projects allows us to gain a deeper understanding of our client’s product challenges and opportunities. This is achieved through the research, stakeholder interviews, ideation, prototyping and user testing activities we conduct. Throughout these workstreams, we may uncover a new finding that sparks an interesting idea, which reveals a whole new interaction model. These activities are inherently prone to introducing scope creep, so we take proactive measures to ensure we remain on track and aligned with our project goals.
One of these measures is documentation. Important questions to ask early on include, “Does a newly introduced feature qualify as a project requirement? What challenge does the introduced feature solve and how does it push the overall project goals forward? Are there significant technical implications for the scope change being evaluated?”
Another measure we implement is sandboxing. We try to limit scope creep by conducting sandboxed ideation, concepting and prototyping phases that allow us to explore wildly different approaches where nothing is off the table. Having this dedicated time allows us and our clients to refine the true scope and create a roadmap that focuses on delivering the highest priority features for the product.
Lastly, there is continuous alignment. It’s important to continuously align on project priorities with our teams and clients. We achieve this through weekly client check-ins and daily team stand-ups where we discuss the overall project status, roadblocks and open questions.
"It’s important that your team and client fully understand feature prioritization.”
When scope creep does occur, how does your team handle it?
When our projects kick off, we work with our clients to identify the business goals the digital product is meant to achieve and agree upon KPIs. This allows us to examine a given idea or feature against those original goals and KPIs and continuously review and prioritize features with our clients.
If scope creep does happen, it’s important that your team and client fully understand feature prioritization. Strong communication and trust between all project teams and stakeholders help facilitate the balancing act between delivering the best possible product and working within the limitations of timelines, resources and budget. With a strong understanding of priorities, teams are able to react to scope creep more effectively as the feature prioritization process is continuously exercised. By having comprehensive documentation, you will have a clear process that allows you to mutually agree on what may slide in and out of scope as project priorities shift.
What other advice do you have for developers looking to better manage scope creep?
Including your clients in your design or development sprint-planning process will not only provide transparency, but also align expectations. This allows your clients to see the work as it’s being performed and gives them visibility into how the project is tracking. In addition to daily technical stand-ups, having your technical leads participate in the appropriate strategy, design and project management meetings can also be helpful in maintaining visibility into other teams that may impact your scope. If you feel you’re becoming at risk of scope creep, engage your product management team more closely. Together with your product manager, you can build scope consensus amongst your colleagues and key stakeholders.
Common
Frankel is able to keep miscommunication to a minimum with an in-house engineering team at Common. Every project that experiences scope creep can be turned into a learning opportunity. Asking preventive questions like, “Is this feature necessary?” before implementation can save time and money.
What proactive measures does your team take to limit or prevent scope creep?
The engineering team has critical processes in place that automatically limit scope creep up front, and then a secondary follow up to keep our goals on track and catch anything we may have missed. Our biggest tool in preventing scope creep is the upfront work of our project managers that determines initial project requirements with key stakeholders.
Project managers own this from start to finish and establish a clear boundary between stakeholders and engineers. With this structure in place, it frees up my engineering time to code and get into the nitty-gritty of the task at hand, without having to worry about negotiating deadlines or additional requests from others. On the development side, we expect our engineers to be self-aware and able to identify when he or she has veered off course into a mindset of perfectionism instead of focusing on the tasks at hand.
When scope creep does occur, how does your team handle it?
Common’s engineering team is completely in-house, and this allows us to establish requirements and priorities for each individual project with limited miscommunications. When we do notice some scope creep, first we determine if it is justified or unjustified. Flexibility is so important in what we do. It is vital for our team to be able to add in new tasks or objectives to a project when absolutely necessary, but know that it’s not the default. We don’t operate off of a “zero-scope-creep” policy, but attempt to manage expectations upfront.
A challenging task for any development team is deciding whether or not it’s the right time to be adding a new feature or if it’s better to prioritize efficiency in delivering a project. We’ve established trust between our project managers and engineers, which has created an awesome culture of transparency on deadlines and capacity. This means we always know what it takes to meet requirements.
"It’s vital to be human in the process of managing scope creep.”
What other advice do you have for developers looking to better manage scope creep?
A maxim from one of our senior developers is, “What’s right versus right now?” As an engineer, I’m constantly asking myself if the additional tasks I want to add to a project are necessary within the timeframe I have.
It’s also vital to be human in the process of managing scope creep. Sometimes, it's rewarding to work on something outside the scope of the project in front of you. Remember that everyone on your team is pushing toward the same goal and trying to get better at their jobs as individuals. It’s in our human nature to be creative and problem-solve. I truly believe creativity and innovation should be recognized and encouraged in the right ways. Managers shouldn’t be afraid to give feedback and make sure the team is aligned on project goals throughout the process. When engineers feel empowered to be creative and thoughtful in their day to day, scope creep becomes much more manageable.
Clear
To prevent scope at Clear, an identity platform leveraging biometrics, Software Engineering Lead Val Akkapeddi said he makes sure goals are specific and measurable. Proper planning and the right preventive actions result in clear communication across all teams. There will be changes and opportunities for improvement, but they should be stated and agreed upon before anyone acts on them.
What proactive measures does your team take to limit or prevent scope creep?
We are built around enabling frictionless experiences using biometrics in a variety of different applications such as airport travel, sports and car rentals. As the core team that enables all of this, the biometrics team is directly answerable to many stakeholders, including various business development groups, infrastructure and operations. Given the number of asks and the number of directions from which they originate, scope creep often feels more like an inevitability than a possibility.
We stay ahead of this by articulating clear goals that state upfront the value that each project is trying to capture. Center conversations around minimum requirements to achieve those goals. Ask stakeholders to reevaluate ideas that claim to bring benefits beyond what we wanted to achieve in the first place.
We also make sure that the goals are specific and measurable.
As well, we defend against internal scope creep from the engineering team. This is not to say that technical improvements should not be pursued, but be tactical about addressing tech debt and technical improvement so that your team gains leverage toward better delivering the project goals.
Lastly, set expectations right at the inception of the project about how changes to the committed scope will be addressed. For instance, if one person suddenly gets an idea, they should not run off and divert from the original plan; instead, all stakeholders should achieve consensus on any deviations from the original plan. Program and product management are an excellent mechanism to drive this.
When scope creep does occur, how does your team handle it?
When scope changes, either the resources and capacity to deliver the scope have to change, or we have to scale down our commitment to delivering something else.
To help manage this, I make sure that my team’s commitment is captured in Jira tickets sorted in priority order. If we need to handle scope changes, this makes it easy to identify the lowest priority items to defer to a future sprint. Having a solid relationship with our product team is key to this, because they can help make decisions around the priority. Another thing that helps is having reliable estimates for the amount of effort required to deliver each objective so that you can effectively decide how much of the previously-committed work needs to be deferred.
"Ultimately, it all boils down to planning.”
What other advice do you have for developers looking to better manage scope creep?
Ultimately, it all boils down to planning. If you have a project plan that clearly states its objectives and is accurately estimated and prioritized, it is going to be a very resilient plan. You will be able to defend against scope creep that does not add value, and you will be able to absorb any short-term scope changes without compromising the ability to deliver long-term.
<weavy/>
“Cutting scope is not necessarily the same as cutting quality,” Linus Birgerstam, CTO of <weavy/>, said.
Scope creep is a common part of business, and is typically considered a negative challenge. But for the tech leader and his team at the white-label full-stack development framework, it can actually have the opposite effect: scope creep can highlight a potential area of improvement and reduce work the team may have to do further in the development process.
“Sometimes we realize the reason we’re seeing scope creep is because some features are redundant or only stealing resources from things that matter more,” Birgerstam said.
To better manage the unanticipated work and the steps needed to see a project through, the product development and project management teams set scope together. This level of collaboration offers the communication and transparency project managers need to work through business challenges and deliver clients the best product possible.
Linus Birgerstam
CTO
What proactive measures does your team take to limit or prevent scope creep?
We work with fixed deadlines. Right now, we utilize the six-week cycle as proposed by the “Shape Up” method. This practice means we have set cycles but variable scopes, which allows us to cut scope and deliver on time. Our whole team is involved in setting scope to make sure it fits “in the box,” so to speak. But naturally, we have to be in close contact with project managers so that they know what to deliver to the client at the end of a cycle.
THE SHAPE UP METHOD
The Shape Up method recommends that teams divide segments of product work into six-week increments. The shorter rotations allow teams to prioritize the most important tasks and reduce the risk of late delivery, all while giving devs enough autonomy to made adjustments without unnecessary micromanagement.
When scope creep does occur, how does your team handle it?
We pose a couple of questions internally to decide how to cut scope, such as, “Can we ship without this?” or, “What happens if we don’t do this?” Sometimes we realize that the reason we’re seeing scope creep in the first place is because some features are redundant or only stealing resources from things that matter more.
What advice do you have for developers looking to better manage scope creep?
Cutting scope is not necessarily the same as cutting quality. Scope creep is there for a reason: it’s a sign that something is wrong with the project or that it just hasn’t been thought through. We may actually raise the quality of a delivery by cutting scope, while avoiding scope creep at the same time.
GigSmart
Chris Downard
VP OF ENGINEERING
Downard said feature production teams should only allow scope creep if the new development work will tangibly enhance a project’s outcome. Teams should communicate proactively about managing scope creep, and features that aren’t vital likely don’t require immediate attention and can be addressed at a later time.
What proactive measures does your team take to limit or prevent scope creep?
At GigSmart, we fully vet, plan and discuss features and initiatives prior to development. Our features go through a robust process prior to writing the first line of code. The process includes creating detailed wireframes, conducting market research, creating prototypes for usability testing and rolling out feature introductions with the product delivery team. We conduct architecture reviews and host multiple meetings with the development team delivering the feature. All these processes ensure we have planned to the best of our abilities. We see one of the most common reasons for scope creep is working on an initiative that’s not fully fleshed out during the design, planning or delivery process.
"Consistent and quick releases also reduce the temptation of scope creep.”
When scope creep does occur, how does your team handle it?
When scope creep occurs, the first thing we do is stop and acknowledge that we are introducing scope creep into the initiative. This awareness leads to discussing the necessity of the scope creep. If deemed necessary, target delivery dates are revised and communicated.
If target delivery dates cannot be adjusted, then the team discusses ways we can potentially reduce scope in other areas of the project. We review options for parallelization of effort and look into whether there are additional team members we can pull onto the project to keep it on track.
What advice do you have for developers looking to better manage scope creep?
Try not to panic or get upset when scope creep happens. It’s not always the product team’s fault, and shared ownership and early feedback reduce its impact. Potential impact to a project will be lessened if a developer with concerns about a feature voices them early.
Scope creep should arise out of necessity, not from forcing more features into an initiative. If we have to add scope to have a more positive delivery outcome, then it should be added. But if scope is being added because something is a “nice-to-have,” then it can, and should, wait.
Consistent and quick releases also reduce the temptation of scope creep. Releasing features whenever they’re ready reduces pressure, which ultimately leads to more on-time releases.
Pairin
Jacob Shanesy
PRODUCT DIRECTOR
Start with the basics. Shanesy works closely with developers and stakeholders early on to map a project’s most essential features. If planning goes well, the fundamentals are often all that’s necessary for delivery.
What proactive measures does your team take to limit or prevent scope creep?
At Pairin, we have many strategies to ensure scope creep doesn’t become an issue, like delivering in rapid iterations, defining phases upfront and having a clear system for stakeholders to track when requests will be addressed and put into the roadmap. Our stakeholders include our clients and teams such as customer success, marketing, leadership, engineering, design and product. We also have a weekly roadmap meeting that ensures everyone knows what is and, maybe more importantly, what isn’t included in each release.
"Facilitate consistent, clear and concise communication between stakeholders and developers.”
When scope creep does occur, how does your team handle it?
At the beginning of each project, we clearly identify the development phases and seek to understand the user’s needs, which can differ from those of the individuals paying the invoices. This understanding allows the team to make decisions centered around data. Typically, we build a bare-bones first iteration, and more often than not, we find that we don’t need to add a ton more for our stakeholders to realize value.
What advice do you have for developers looking to better manage scope creep?
Scope creep is the result of mismatched communication between your development team and stakeholders. As a product manager, I find it key to facilitate consistent, clear and concise communication between stakeholders and developers. Additionally, working at an early-stage growth company, it’s important to architect and design with a sense of flexibility. When things are built correctly, we find that features and requests that normally could be considered scope creep are actually fairly easy problems to solve because we built for flexibility from the start.
Procare
Stephen Smith
SOFTWARE DEVELOPMENT MANAGER
Urgency is a key part of product development, especially when applied to managing scope creep. When unexpected work presents itself that might delay production, Smith and his team at Procare meet to discuss an immediate plan of attack. Occasionally, that plan requires a joint development effort in which engineers work in tandem to hit deadlines.
What proactive measures does your team take to limit or prevent scope creep?
Scope creep affects us the most when it’s unclear what the scope of a story is. Or when a developer wants to develop the story a certain way without buy-in from the rest of the team. So we have story-grooming sessions early where the dev team analyzes a story and plans out what it would take to complete it. We won’t move on until the team is comfortable with what needs to be done and how it will be accomplished. Sessions involve dev team members as well as the product owner to provide product clarity.
"Communication is the key to managing scope creep issues as they come up.”
When scope creep does occur, how does your team handle it?
Even if early planning and estimation are done correctly, scope creep can still happen when running into unexpected things in the code or if priorities change mid-stream. In this case, we immediately talk about it as a team and start working around the issue. People working on a lower priority feature may pause their work and swarm on the item that is unexpectedly taking more time.
What advice do you have for developers looking to better manage scope creep?
Communication is the key to managing scope creep issues as they come up. It’s vital to immediately talk to the team if something is starting to take longer than was planned or if more work is necessary to accomplish a task. People can be stopped from going down rabbit holes if there’s good communication, and they can be pulled up before they get too deep.
Sprout Social
At Sprout Social, leadership places equal importance on defining problems they want to solve and avoiding challenges they don’t want to tackle in order to define the full scope of every project. Stanton emphasized the difference between preventing scope creep and skimping on testing the performance of important features.
What proactive measures does your team take to limit or prevent scope creep?
Before beginning a project, stakeholders clearly outline its criteria for success. Next, we engage the whole team, including product, design and engineering, to come up with milestones and a timeline.
When we’re ready for implementation, we take an iterative approach of deploying code early and often. This approach is essential to limiting scope creep as it prevents feature branches that extend for months on end.
"Be proactive in getting clarification when things are inconsistent or contradictory.’’
When scope creep does occur, how does your team handle it?
It all goes back to clearly defining the problems and scope up front and making sure everyone is aligned on the success criteria. If we do this correctly, everyone is equally responsible for addressing scope creep and determining whether or not new scope is essential to the success of the project.
If it is a blocker, we either accept it as part of the scope, find a creative way around it or cut something else. We document these decisions so that the team can stay focused on the work at hand. We know that we can revisit the discussion if a change becomes essential later on.
What other advice do you have for developers looking to better manage scope creep?
Be proactive in getting clarification when things are inconsistent or contradictory. While vocalizing potential obstacles is helpful, don’t assume something is essential without talking to the entire team. If it truly needs to be part of scope, the team will agree with you.
Lastly, don’t skimp on testing or performance for important features. Those things should not be considered scope creep. They are part of building quality software and delivering a product that fully meets your users’ needs.
Beyond Finance
According to Rabiela, Beyond Finance relies on product managers and software engineers to keep the software delivery cycle on track during sprint planning. On the rare occasion that the team decides to add a feature post-production, they ask themselves what the smallest possible addition or change would be in accomplishing their goal.
What proactive measures does your team take to limit or prevent scope creep?
Keeping a short and regular software delivery cadence goes a long way in preventing scope creep. If your engineering team is constantly releasing new features and fixes, there is less of an urge for people to add scope to the work being done. Product managers and software engineers share the responsibility to keep deliverables small so they can be shipped in under a week.
"Scope creep doesn’t only affect you as a developer.’’
When scope creep does occur, how does your team handle it?
We initially try to avoid changing the scope of the work that’s currently in play. We’ll wait to add new features or functionality until after we wrap up what we’re currently working on. There is a decent chance that we’ll release what we have, reevaluate if additional scope creep is needed and finally decide that it’s not.
If the scope creep causes us to change what we’re currently working on, then we try to keep the creep to a minimum. Our goal is to deliver an MVP of the feature we’re building. We apply that same MVP rationale to the new scope coming in. What is the smallest possible addition or change we can make to accomplish what we’re looking for?
What other advice do you have for developers looking to better manage scope creep?
Scope creep doesn’t only affect you as a developer. It also adds time and complexity to any QA efforts, release plans and post-release triage. Try to keep projects small for an all around smoother process.
Ellevation Education
Joe Roberts
ENGINEERING MANAGER
Between formal status meetings and efficiency-improving processes like the RACI matrix, Roberts’ team works to stay on top of any changes to a project’s scope. Communication and progress-tracking build the foundation of their scope management practices, but the team also gives themselves extra time to adapt to any major changes.
What proactive measures does your team take to limit or prevent scope creep?
At Ellevation Education, we use Scrumban to manage and define our work and track our team’s capacity. In addition, we leverage objectives and key results to ensure the team is focused on executing work that is aligned with our company’s objectives. Our team has developed habits and rituals to prevent scope creep, like quarterly OKR planning, weekly Kanban board-grooming and daily status stand-up meetings to report on our progress and blockers.
We use the RACI (responsible, accountable, consulted and informed) matrix to define stakeholder roles on any ongoing or new initiative. Using RACI establishes clear roles, responsibilities and expectations for an activity or decision being carried out by the team. If there is a change to the scope of a project, the person responsible for executing will work to reset expectations on deliverables, milestones or timeline.
"We often develop new features with a minimum viable product mindset.”
When scope creep does occur, how does your team handle it?
In the engineering organization, we think having a short feedback loop on new features is much more important than getting a new feature to be “perfect” on release. Therefore, we often develop new features with a minimum viable product mindset and solicit feedback from our stakeholders to inform and gauge our progress.
Inevitably, there are times when a change to the scope is introduced mid-cycle based on stakeholder feedback. When that happens, we’ll work with the product manager, team leads and other business stakeholders to redefine the scope and deliverables. We’ll sometimes re-prioritize other work within the scope that will allow us to fit new requirements into the project. My team also doesn’t allocate 100 percent of our time to an iteration to ensure we have a buffer to deal with a significant change.
What advice do you have for developers looking to better manage scope creep?
Define how requirements are collected and managed to create a project’s scope and estimate the time and effort required to complete tasks. Make sure the problem is understood before code is written. Ask clarifying questions if stories or tasks aren’t clearly stated.
Knowing a stakeholder’s “definition of done” upfront will also be important to avoid a project that won’t end because the deliverable is a moving target. Consistent communication of a project’s progress with stakeholders will provide them with additional data so they can make informed decisions or changes that impact scope. And avoid gold plating once you’ve delivered a solution that addresses the baseline scope defined.
Lose It!
Steve Massaroni
SENIOR IOS SOFTWARE ENGINEER
Keeping expectations grounded in reality is how Massaroni’s team approaches product development. Massaroni said product developers should build and deliver new features to users based on what already exists, rather than aiming for conceptually perfect iterations.
What proactive measures does your team take to limit or prevent scope creep?
At Lose It!, our battle against scope creep begins at the start of our development cycle. Representatives from every department hold a planning meeting where anyone in the company can pitch ideas. The output from this meeting is a set of objectives and the time we’re willing to invest for each.
By planning our work in those terms — objectives and time budgets rather than features and estimates — our developers are tasked with designing from the bottom up to find a minimal possible solution. From there, we embrace scope creep through iteration. If we’ve succeeded in our planning efforts, scope creep can only occur through changes to our objective or the minimal solution.
"Compare new ideas to the current version of the app, not the ideal version.”
When scope creep does occur, how does your team handle it?
We have a few options. If we can, we will cut something from our minimal solution. A cut is our best move because it solves one problem with another. If we were perfect, we would have cut the minimal solution down initially.
We also could push back the minimal solution, reducing our opportunity to iterate. Doing so is a brute force move that we have to deploy carefully. If we push solutions back too much, we will spend all of our time budget and won’t be able to iterate. Worse, if it becomes a habit then we won’t be addressing the problem of scope creep at all. Finally, we could revisit the design, which is a drastic move because we won’t get back any of our spent time.
What advice do you have for developers looking to better manage scope creep?
Compare new ideas to the current version of the app, not the ideal version. Focus on delivering an immediate improvement to users. Otherwise, ideas will never stack up and the team will be overwhelmed by how much work they have ahead of them.
Don’t push back against scope creep directly. When someone approaches you with an idea that is likely to lead to creep, fighting against that idea will put it in the spotlight and galvanize its proponents. If the idea is embraced, it can end up in the iteration phase where it belongs with a little social finesse.
Formlabs
Ben FrantzDale
PREFORM DESKTOP SOFTWARE TECHNICAL LEAD
The simplest solution is sometimes the most effective. FrantzDale said pushing for simplicity by stripping a project’s goals to its bare bones helps the dev team limit scope creep, keeping the ultimate focus on the user.
What proactive measures does your team take to limit or prevent scope creep?
At Formlabs, we focus on a small number of products with a specific set of user-facing features that we keep as straightforward as possible. To achieve this goal, we regularly have conversations with product managers and other stakeholders who understand our customers. This practice also requires a deep understanding of how our software works and a creative eye for ways to implement new features.
"Sometimes, the best feature is no feature.”
When scope creep does occur, how does your team handle it?
When I feel that a feature is creeping, I first try to assess why. Sometimes features creep for good reason. For example, a feature may be small, but to implement it cleanly requires refactoring. In that case, it can make sense to do the refactor along with the feature. On the other hand, particularly in a release branch, it often makes more sense to back up and take a simpler approach that accrues some technical debt. Then, add a code comment and a ticket to note the tech debt we’d like to resolve in the future.
In other cases, what feels like feature creep is really a scope that wasn’t fully understood. In those cases, sometimes it makes sense to shelve the project. Other times, if the feature is important, it can make sense to continue even if it means letting it slip into a later release.
What other advice do you have for developers looking to better manage scope creep?
Write feature descriptions with a clear definition of what “done” looks like. Be brutally minimalist about that definition and don’t be afraid to pare it down further if appropriate.
Oftentimes, the initial vision of a feature includes user interactions and UI elements. But when paring things down to a minimum-viable feature, we often find that there’s a feature the user may never know about that works just as well, which doesn’t add any visual clutter or cognitive load for the user. And because there is no UI, there’s less to design, wire up, test and maintain. Sometimes, the best feature is no feature and the best UI is no UI. It’s all about understanding how hard different approaches are to implement and maintaining a laser focus on the product and customers’ needs.
Planoly
Andrew Clements
IOS ENGINEER
What proactive measures does your team take to limit or prevent scope creep?
In order to limit scope creep, we try to make sure that we have a clear understanding of what we’re trying to accomplish prior to jumping into a new feature. We’re usually working with the product owner and designers to make sure that we’re hitting all possible flows, including the not-so-happy paths.
When scope creep does occur, how does your team handle it?
At Planoly, when we do encounter scope creep, we make sure that we have enough time to test the additional work coming in. In order to keep the project on track, if something needs to get pushed to the next sprint, we prioritize that adjustment.
Most of the time we’re able to add the additional scope into the sprint because of the buffer we include in sprint planning. We typically don’t have issues adjusting our timelines.
Include the possibility of additional scope in your sprint estimates.’’
What other advice do you have for developers looking to better manage scope creep?
Include the possibility of additional scope in your sprint estimates. It’s always better to overestimate how long something is going to take and have the ability to move up the release. You don’t want to run out of time and have to push the release further back.
