Depth of scope
When having a discussion about the negotiable-scope nature of some Agile processes (XP for example) an inevitable discussion about the “variables” of a software project arises. I usually abbreviate the “variables” as Q R S and T: quality, resources (a.k.a. cost), scope, and time. Many projects try to fix all of these variables and are subsequently shocked that they failed to meet their estimates on one of them. Something has to give, many Agile proponents argue that it should be scope.
Many business stakeholders are uncomfortable with negotiable scope projects because they feel like they won’t get all the business functionality that they need if they have to negotiate the scope. This is typically a concern of reducing the bredth of the scope — people don’t like to get rid of user stories, so to speak. But, another way to reduce scope is to negotiate the depth of your scope. The depth of scope is how complicated or time-consuming the requested or proposed implementation of a business requirement is.
Here is an example of reducing the depth of your scope: your business requirement may call for a screen to add users to roles. The person defining the requirement may ask for a way to dynamically drag-and-drop stick figure images that represent people onto images of buckets that have the role names on them. When you get to this user story (or at the iteration planning meeting), the development team estimates this as 8 story points. The business person comes back and says, “WOW, that much for such a small portion of the overall functionality needed for the next release?”. This is where you can negotiate the depth. You come back with, “This could be accomplished using regular HTML elements such as checkboxes, radio buttons, or drop down lists and only cost 2 story points”.
But technical people are also guilty of increasing the depth of scope. Technical people often overdesign or overarchitect solutions. Sometimes, they like to use technologies that are less efficient, because of preference or ego. Sometimes they only provide overly complicated implementation options in planning meetings because they don’t like the thought of “hacks” going into their precious system. A good way to try and avoid “technical-person scope creep” is to use Story-Test Driven Development (STDD).