How to Control Feature Creep But Allow Changes to the Project

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:

  1. The only work the team members can do is work that is added to the sprint backlog.
  2. Only the Scrum Master can add work to the backlog.

  3. 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.

1 person has left a comment

Usually feature creep results in overtime- a lot of it- in my experience. But, I do agree that before adding work the team/ team member definitely needs to finish the work they already have been assigned. Otherwise, neither one will get done, or will be done haphazardly. Nice post, Anne-Christine.

Richard Larson wrote on November 18, 2013 - 1:57 am | Visit Link

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories