How to Control Scope Creep in Ag

转自 https://www.thoughtworks.com/insights/blog/how-control-scope-creep-agile

What is scope creep in agile?

It would be scope creep if the stakeholders want to swap new work for work already completed. 

It would be scope creep if the stakeholders want to swap something big for something small. 

Agile rules engagement

1. It's not scope creep if you're changing something before the team has started to think about the details.  In an Agile SDLC, we lay out the planned work at a high level before we start, to make sure we're in general agreement about how much the team will get done, but once the general size of the effort is agreed, details are purposely left to be determined later.  At the "planning game" stage of the project, we might specify that we need a user interface with about 10 fields.  But we don't specify what the exact fields are, what the validations on the fields will be, nor where they will park in the database, until we are ready to do actual development on that story.  Why do we wait?  To avoid scope creep even coming into the conversation!  This method allows you to change your mind without penalty, and to give you and your company a competitive advantage over product owners in other companies who are kept to their original contracted scope.

2. It's not scope creep if it doesn't create additional work for anyone.

3. It's not scope creep if it's within the team's defined contingency allowance for "unknown unknowns."

How to control it?

If you're an agile team, you point to your pile of completed work, your team's track record for delivering every two weeks, and your projected delivery date for the next production deployment.  You say, "We have committed to this plan, and we are delivering to it with fully production-ready code every two weeks.  If you add additional work, we will not be able to deliver on time.  Here is our evidence."  Notice that you're not having a conversation about who said what six months ago.  You are all squarely focused on the delivery date and the probable contents of the software to be delivered on that date.  You are all securely committed to keeping quality constant, rather than agreeing to allow more work to creep into the schedule.  That's the responsible conversation to be having, so that's really nice.