How does scope creep occur?
To implement the variation metric as a solution, it is important to first understand how 44% of businesses in 2015 experienced scope creep'. The first part of the answer is that the likelihood a project will experience scope creep is very high. Largely, this is due to the number of ways in which it can infiltrate a project. One example is if a customer has moments of clarity or epiphanies that result in even minor changes to the current sprint (minor changes can add up to a significant impact). Another is when the lack of details from the stakeholders are only identified after more careful thought about what it really entails to complete a sprint. These are the two major entry points of scope creep that a project manager should be aware of.
The second part of the answer is that there can be ineffective management of scope creep when it does occur. Generally businesses build a project from a product backlog filled with requirements. These requirements are prioritised and the ones that help create the most basic functionality of an app form the first sprint. The other features are grouped into subsequent sprints according to their priority. This strategy is important to the agile methodology because it allows a business to replan and optimise later releases at the earliest point possible, in order to create the best product/market fit. Building agile reduces the chance of unnecessary expenditure as well as the risk that a developer will spend unnecessary time on building requirements that would eventually need to be adapted to work with changes to the basic features.
However, some businesses allow customers to swap requirements during a sprint of the development process. On the surface this may seem like a good idea but in practice it can be difficult to do. The issue is that the swap can affect the dependency relationship between the different requirements in the sprint. The diagram below shows how removing one requirement can impact on the relationship between the others and therefore the overall functionality of the app. These kinds of changes can lengthen the time of a sprint to a degree that negates the effectiveness of working with agile methodology.
Introducing the Variation Metric
At WorkingMouse our solution is to use a variation metric and apply particular scope management techniques depending on where each partner (customer) is ranking. The variation metric helps us measure how much the requirements change during a sprint when compared with the original scope. You can see how this works in the image below. Say there is a project with 20 issues and the partner wishes to change one of these. The change would amount to a 5% variation. However if the partner wanted to add an issue as well there would be a total of 21 issues, with 2 changes and a 9% variation.
Adding up the overall variation allows us to rank the partner at different levels of scope creep. Depending where the partner ranks, you can apply particular management strategies. For example a partner might be flagged as having reached warning level (0-5%). This alerts you to review the project and identify how the scope creep has occurred. Upon investigating, you may identify the cause as being a miscommunication between your business and the partner regarding the details of some functionality. As a result you can manage this communication failure by reviewing knowledge transfer sessions and ensure that the functionality is adequately represented in the requirements backlog, UX flow and schematic diagram.
If the variation metric climbs further, this might flag that the communication issue runs deeper. Upon examination it is likely you will find that your partner's vision continues to evolve past the MVP (minimum viable product). While it is great for them to have future aspirations for the product, the scope is the MVP and not the lifetime of the entire project. It is for the benefit of both parties to stick to the build, measure, learn ethos. Therefore to manage this kind of scope creep you should review how you are managing your partner's expectations.
The difference between our strategy and others is we have a limit on scope creep. If the variation metric exceeds a threshold then a sprint fail has occurred. This means too many changes have been made for the sprint to be worthwhile continuing. The approach at WorkingMouse is to not let scope creep pass our manageable threshold. If it does then it is in the interest of all stakeholders to halt the build until we find a solution.
Summary
While our management strategy is not the only solution, it is important for all businesses to consider how they will deal with scope creep. All software developers will at some stage experience scope creep in their projects. The key to a successful build is in how your business identifies these risks and implements management strategies.
From a management perspective, by identifying scope creep as it happens, in real-time, you gain the opportunity to manage the expectations of all stakeholders. And if the variation is outside of what management considers tolerance, actions can be taken by either revisiting the price or the allocated resources.
