Sep 20 2018
When planning out a software project, you’ve carefully budgeted for and scheduled out your team’s work—but once you get down to business and start building the product, a common problem may come up: Scope creep.
Not all projects go exactly according to plan—in fact, most don’t. But when you’re not prepared with a plan to deal with last-minute changes within the structure of your project, this can cause problems for your agency or organization. That’s particularly true if you’re working on a fixed budget and/or a fixed time frame—both of those can fly out the window before you know it.
Here’s a look at why scope creep happens—and what your agile development team can do to stop it in its tracks.
Scope creep can happen for any number of reasons, as any developer likely already knows. These are a few of the most common things you might hear:
If you work for an enterprise, scope creep can hurt productivity and push back timelines—and if you work for an agency, it can also greatly impact your profitability. But with experienced agile project management, it doesn’t have to happen.
Here are some of the best ways to proactively keep scope creep out of the picture on your software projects:
Build out a detailed list of product reqs before you start so the client knows exactly what they’re getting, and don’t leave room for variances. Your product reqs should illustrate how your team plans to prioritize release cycles, focusing on building the solutions that help the greatest number of users first. Showcase the features you plan to build and the technology stack you’ll use to build them in each cycle.
Even though your client or business stakeholder might have a great idea later in the process, be clear that you need to stick with the existing SOW, and save that feedback for later releases. Your product manager will likely be the point person responsible for responding and providing feedback to the higher-ups, so make sure that you provide a unified front and let him or her refer back to the existing project specs any time a new request comes up.
Many agile product development agencies work in “sprint” sessions that bill by block of time, not by milestones met. A typical sprint is generally two weeks in length, and includes the work of the entire development team within that time window, with the goal of completing a series of identified features. However, the number of features completed shouldn’t be tied to the cost: Development work is unpredictable, and the workload can’t be easily determined before you dig in.
Each day, your dev team should hold “stand-up meetings” to discuss their priorities for the current product release cycle, and whether they are facing any roadblocks or need support from others on their team. This will help you build a transparent and collaborative team, and enable each member to be proactive in moving the project forward if it stalls.
It’s also important to regroup with the client or business stakeholder regularly to go over what’s been built and whether there are any roadblocks to accomplishing the next goal—typically, at the end of each 2-week sprint cycle. If, based on the development cycle, it turns out that changes are needed to the overall plan, your team can then map out updates to the product requirements and budget/timeframes accordingly. Things may shift along the way, but you’ll be able to re-scope and map out expectations as you go along.
As you no doubt already know, development projects don’t always go 100% according to plan. Features don’t always work, or can take much longer to build than planned. But by developing a smooth agile process with ample opportunity to regroup and re-scope along the way, your team can ensure that there are no surprises when it comes to the scope of work from start to finish.
Want more? Head back to the Tivix blog