In 2018, more than 50 percent of the projects completed by 5,400 project managers experienced scope creep, according to a report by the Project Management Institute.
As projects change, scope creep can be created by team members, stakeholders and even users, who unexpectedly — or intentionally — expand a project’s scope. But tech professionals across Boston say that scope creep can be managed effectively when teams have clear definitions of what a project’s outcome should be.
“Write feature descriptions with a clear definition of what ‘done’ looks like,” Formlabs Desktop Software Technical Lead Ben FrantzDale said. “Be brutally minimalist about that definition and don’t be afraid to pare it down further if appropriate.”
Working toward achieving a minimal solution cuts down on the opportunities for scope creep to occur. Steve Massaroni, senior iOS software engineer at weight loss app Lose It, recommends keeping production from becoming too complex and features from being too idealistic. This technique, Massaroni said, allows Lose It to rapidly release features and have a greater impact on users.
Meanwhile, Engineering Manager Joe Roberts said his team at edtech platform Ellevation Education use short feedback loops with stakeholders and progress-monitoring methodologies like Scrumban to get implementations out the door quickly.
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?
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.
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?
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.
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?
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.
