In traditional Waterfall projects we had to be careful and beware of the dreaded Scope Creep… That evil demon that creeps into your back log as overachieving team members agree to do undocumented change requests that come in after the project planning and budget have already been done. Historically to avoid scope creep organizations have required adherence to strict change management policies that restrict changes of any form with extensive approval, requirements document update and sign off and negotiation of an amended contract. That’s NOT Agile!
The Agile Manifesto States that we Prefer Customer Collaboration over Contract Negotiation and Responding to Change over Following a Plan. What this really means is the customer wants what the customer wants… If the planned solutions as defined by the requirements does not meet the customers needs then we are doing the customer a disservices by saying the “The contract says we are only allowed to build whats in this requirements document”. You wont get much repeat business with that line of thinking. In my experience the customer doesn’t seem to know what they want until you build what they asked for, then they know for sure that is NOT what they want. So its best if we work in short iterations and get feedback from the customer confirming we are building what they want and if there are any adjustments they would like to make. While this idea of Customer Collaboration over Contract Negotiation allows the Agile Delivery Team to Respond to Change over Following a Plan if not managed correctly it can quickly erode the profits from App Dev.
Enter the Triage Triangle. The Triage Triangle is a tool that we can use to illustrate to customers and stakeholders the impact of unplanned changes on Delivery Date and Cost. In traditional Waterfall projects the scope was rigid and fixed (tied to the contract) as a result any unplanned changes that were included expanded the scope causing delivery date and cost to slip. On an Agile project we keep the Delivery Date and Cost fixed and allow changes in scope even late in the development process with the understanding that if the project Scope is expanded then one or both of the other sides of the Triage Triangle must be adjusted.
For example if we have 100 story points worth of planned work to complete and the customer decides that they absolutely must have this new unplanned feature 10 story points in size than we can do 1 of 3 things:
1. Trade a feature of equal size and story point value
2. Keep existing features and add the new feature increasing cost to cover the additional work and pushing the delivery date.
3. Keep existing features and add the new feature increasing cost enough to cover the additional work without pushing the delivery date. (hiring additional resources will cost more)
