How do you deal with changing requirements? [closed]

Question

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?

Answer 1

@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.

Answer 2

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.

Answer 3

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.

Answer 4

This is a very common problem, no matter how fast a project is advancing on technical terms the client perceives it as going much much slower and feels free to change requirements as they like thinking that the developers must not be doing much anyway.

This flawed perception comes from three major development tasks that consume time and will never be accounted for properly by clients:

1. Code reviews / clean-up: Old code gets bloated and messed up and needs regular reviews and clean-ups, this takes a lot of time and the client will never believe it.
2. Security audit and fixes: Especially if you have junior team members you will have a lot of code related security problems and you will want to go regularly through all that new code that has been written and rewrite stuff that doesn't look good from a security perspective, the client will never know or account for this time.
3. Architecture related changes: A growing code base may (and most likely will) at multiple points require structural rethinking and refactoring this may involve: A - Performance-related changes/optimizations (Algorithm changes, library replacements, cache engines, ... etc) or: B - Productivity-related changes/optimizations (readability, code-reusability, ease of understanding, new coding conventions, a new framework, ... etc).

None of the above will ever be understood and properly accounted for by end clients.

Basically whatever has no "views" (GUI elements) has not been done.

Let's call this the projenix theorem, haha no just kidding :D