How I managed scope creep
“You know what would be fun?”
Those few words can cause even the most well-planned project to spiral out of control. I know this too well. I once joined a project halfway through its development just as scope creep was sneaking up on the team. That sentence was uttered by the product owner who was losing sight of the project’s scope and vision. The objective was clear as mud and requirements were fluid.
Features were being prioritised based on whether they were fun or not. When a new task was pulled into the sprint, other tasks were not being deprioritised. This overwhelmed the whole team.
I stepped in to try and reintroduce order to the project.
Revisit project goals
I started out by speaking to several stakeholders to understand requirements and the broader business goals.
Some pictures have been blurred for privacy reasons
I found out that the company wanted to increase app retention rates for mobile wallets. We were working in an Agile environment and that was perfect for an Initiative — an objective with a large focus that will have a big impact on the company’s performance.
Structure the work
Once the Initiative was clear, we started to group smaller tasks into Epics to achieve a common goal. Each time a new “fun” idea was proposed, we could evaluate it and determine if it was relevant to our Initiative.
Example of how the work was categorised (Due to confidentiality reasons, I’ll be using GrabPay as an example for the client):
Having a structure allowed for easier sprint planning and prioritisation. Team members began to have a common understanding of tasks and goals.
Room for improvement
Unclear objectives and a lack of Definition of Done (DoD) requirements led to gold plating — intentionally adding extra functions or features that were not defined in the original product scope. The product owner instructed developers to build extra functionality to please managers and the development team worked on them to prove their abilities.
Transparency in communication and a documented list of criteria to be met for each user story to be considered done could have prevented gold plating.
A simple change control process could also have helped in managing the influx of change requests from stakeholders. For example, every change or idea proposed must be submitted to the team in a format like this:
- Summary of request and why it’s necessary
- The potential impact if it’s implemented or not
- How the change will add value
- Conditions for success
- Expected time needed for completion
This will enable the team and decision makers to analyse requests in a strategic way and prioritise what’s important.
Learnings
Change is inevitable for every project but one must be able to spot the signs of scope creep and gold plating early on to prevent chaos.
Originally published on my website at melvinlim.design
