November 13, 2013 | Author: PM Hut | Filed under: Scope Change Control
How to Control Feature Creep But Allow Changes to the Project
By Anne-Christine Gasc
One of the main causes for slippage is feature creep: work that wasn’t planned originally but got assigned along the way without due diligence. Either the new work will be done at the expense of previously agreed work, or the team will work overtime, or the project will be late. Sometime all three.
However, you don’t necessarily want to lock the work at the start of the project: there should be room to add/update features along the way.
The solution to doing this safely is to have a strict, simple process for assigning work:
- The only work the team members can do is work that is added to the sprint backlog.
Only the Scrum Master can add work to the backlog.
Only the Product Owner can approve work that the Scrum Master adds to the backlog.
This means that when someone (anyone) wants to suggest additional work, they must talk to the Product Owner to convince them it’s worth doing, then the Product Owner must talk to the Scrum Master to agree how it should be done (when, what needs to be removed from the backlog to make room, etc.)
Most people will follow that rule, but some managers won’t, so if someone (anyone) goes directly to a team member to ask them to do work, the answer should be that they’ll look into it – then go talk to the Product Owner and start the process from there.
The way to get the team members to not take on additional work is to put in place a culture where they must commit to their sprint deliveries: if they agree to doing additional work along the way, they must still deliver their sprint commitment even if that means working late or at weekends.
Chances are, they will try taking on additional work a couple of times, and after they’ve spent working late nights and weekend to deliver the feature creep in addition to their sprint commitments, they will understand how the process benefits them and will follow the rules.
Finally, change requests must be processed immediately, i.e. the Product Owner and the Scrum Master must drop what they are doing in order to process change requests. It’s critical for the process to work that those suggesting the change and those doing the work don’t wait more than one hour before getting feedback or the process will be seen as too cumbersome to be useful.
A nice consequence of this rule is that it allows anyone to make suggestions to the Product Owner and give them a chance to influence the direction of the product, while the Product Owner remains the decision maker and retains ownership of the product.
Anne-Christine Gasc is a Project Manager working in the games industry. You can read more from Anne-Christine on her blog.