I’m working with a group that is trying institute good process.  A lot of the team is new, and they all have various backgrounds.  A developer came up to me the other day and proudly announced that he had coded something that was on the roadmap for a future release, but out of scope for the current release.  It was a very small change for him, so he slipped it in. He was disappointed and didn’t get why it mattered when I said “but, that is out of scope”.  Then I broke it down for him:

• I need to update the requirements to include it.
• Everyone who signed off on the requirements will need to review and approve the change.
• The QA team will need to create test cases for the new item.
• I’ll need to review the test cases.
• The QA team will have to execute the test cases.
• The other development team who also works with this will have to similarly update their work.
• (In this case there were no documentation updates to address)

He then got an appalled look on his face and immediately said “I’ll back it out, don’t worry”.

Unfortunately, this is not an isolated incident.  Scope creep and gold plating often happen, without an understanding of the impact.  Being able to clearly explain the impact of the scope creep goes a long way toward getting whole-hearted support of, rather than grudging compliance with, scope control.

I did let him know I was happy he had figured it out and was glad that it would be easy to do when we get to it.