At Beyond Finance, engineers keep releases short and frequent, and for good reason.
In 2018, more than 50 percent of the projects completed by 5,400 project managers experienced scope creep, according to a report from the Project Management Institute.
VP of Technology Sergio Rabiela said developers release existing code before evaluating new, proposed feature branches that could take months on end. Taking last-minute suggestions into consideration as you go can lead to confusion and misalignment. When scope creep does find its way into a product plan, developers address the work using an MVP-mindset.
Engineers at Sprout Social use a similar strategy. Senior Infrastructure Director Kevin Stanton’s team thinks big and deploys small.
“When we’re ready for implementation, we take an iterative approach of deploying code early and often.”
He recommends that teams consistently check in with each other before assuming a feature is essential.
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.
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.
