Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

In my current job it feels like we have a lot requirement changes. We are an "Agile" shop, so I get that we are supposed to adjust and what not, but sometime the change is large and nothing trivial.

My question is, how do you effectively communicate the cost of the change? Because of being agile, if a change is big enough something will get dropped from the current sprint, but it usually just get added next time around. Since our model is SaaS, the end customer is effectively the business itself, and they know they will get the cut feature n weeks later.

I guess what I am trying to get at is the removal of a feature really isn't anything to use for communication as it was only delayed by n weeks. What other ways do you have to get the business to understand what a change costs?

share|improve this question
Related -… – ChrisF Sep 15 '10 at 15:10

3 Answers 3

up vote 11 down vote accepted

@Joe "We are an "Agile" shop, so I get that we are supposed to adjust and what not, but sometime the change is large and nothing trivial. "

If your process doesn't allow you to control the rate of change in requirements, your process is not agile, but haphazard. Agile does not mean "taking anything that comes my way."

To control requirement change/creep you can adopt - in your process - the notion that a requirement does not change (a notion that it's at the heart of Scrum.) Treat a requirement change as replacing an old requirement with a new one. You have to have a backlog of requirements, and you have to have the user choose which ones he/she wants to have implemented.

You wanted X and Y in two weeks, but all of the sudden you want Z. Well, then I can deliver you all three in 4 weeks. Or I can give a pair (X and Z) or (X and Y) or (Y and Z) in two weeks and deliver the remaining one later. Choose.

This is how you negotiate with customers. This is how you communicate the cost of requirement change. If your group does not have that power, you are not in an agile shop, and there is nothing that you can do about it. It sucks, but it's true.

In case where you can negotiate, you have to track (with precision) the time it takes to implement requirements and requirement changes. That is, you have to collect this data from past and present projects.

You collect the original time estimate and the actual completion time (in addition to resources like developer count) per request (or module affected by N requests). Better yet, estimate the size of the request/request change (in terms of lines of code or function points in past projects and requests.)

Say you have a metric that you can talk to the user with. You know that a new request will take, say, 1K lines of code, or 10 web pages with an average of 5 input fields each (50 function points).

Then by looking at historical data specific to your past projects (some by lines of codes, some by web pages, some by actual function points), and you can estimate how each of these cost in terms of absolute completion time. For those with sufficient data, you can also identify those requirements that track an actual developer head count.

Then you use that and you tell your customer that based on historical data; you argue that project failures tend to follow a exponential distribution follow; and then you are armed with the following argument for your customer:

Based on data from our past and present projects and available resources, the requirement you are asking will take

  1. X amount of time to complete with a 25% probability of failure (or 75% of success)

  2. 1.5 * X amount of time to complete with a 5% of failure (or 95% of success)

  3. 0.5 * X amount of time to complete with a 95% of failure (or 5% of success)

The probability of failure as a function of amount of time resources typically go 95%, 25% and 5% (resembling an exponential distro.) You convey the message that a certain baseline amount gives a somewhat decent chance of success (but with real risks). 1.5 of that might give almost a certain chance of success with minimal risk, but than much less than that (0.5 of the original guarantees almost certain failure.)

You let them digest on that. If they still go for the risky proposition (done yesterday!) at least you have in writing that you told them so. If there is hope for your group of not just being agile but engineering-like, then, the customer might put serious consideration into your numbers and schedule this and future requests accordingly.

It is your job as an engineer to explain in engineer, verifiable and clear terms that request changes are not a free meal.

share|improve this answer

From what you described, you don't have a problem. They ask for a change and are either willing to wait until you say it can be done or are willing to postpone another feature. Seems like a balance between: time, resources and requirements.

share|improve this answer
I'm not saying that the give and take is a problem. I am asking how do you communicate the complexity and scope of a change being asked? – Joe Sep 15 '10 at 18:11
@joe you give then an estimate – jk. Nov 14 '13 at 17:23

You could try setting a minimum age of a new addition / change (not applicable to bug fixes). For example no new changes can be worked on until it is 3 weeks old.

Having a minimum age of a task is nice because at the start, every task looks like it's extremely important, but if you wait some time then it's importance will often drop significantly. Depending on your time interval it will give you at least that amount of time of stability in the tasks you're working on.

To track the age you would allow the tasks to be added to some list, but they wouldn't be considered as tasks to work on until that period has expired.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.