Question

Steve Yegge’s wisdom notwithstanding, most developers are faced with requirements which were gathered from non-technical customers. Sometimes there are project managers who deal with the customers and translate their requirements, other times not. In any event, the fact that the requirements will change is an inevitability.

Most of what consititues ‘good programming practice’ has to do with developing systems which are adaptable so that they can withstand changing requirements. Principles like YAGNI, DRY, loose coupling, etc. contribute to this. Iterative development processes such as Agile also attempt to address the concern of trying to hit a moving target, and of course having a system under test makes it infinitely more feasible to make changes.

Nonetheless, it seems that for many of us changing requirements can not only hurt the quality of our software, but can also drain our motivation and make us want to stab someone.

This question is about how to manage the customer to make it possible for them to change their requirements in the ways that they need, while discouraging arbitrary or frivolous changes. How do you do it?

• Do you have project managers to insulate the devs from the customer?
• Do you have a formal change management process? Change managers?
• How difficult is it for the customer to get a change when they really need it?
• Conversely, how easy is it for a customer to get a change when it’s ‘frivolous’?
• How much detail do you give the customer when explaining the cost of a change?
• How quickly are you able to give the customer this information after receiving a request for change?
• What factors can torpedo the process (e.g. PM’s who can’t say no to the customer?)
• What works for you?

Answer 1

If you are looking for the ideal world where the customer never changes his mind or you get the ideal spec – you are in the wrong business. That being said, the most effective mechanism I have found for managing customer expectations and change requests is to institute an accurate system of measurement.

This is how I run my team:

1) We start with user stories. The customer is involved in writing them and the development team estimates how long each user story will take in a relative manner.

2) Using prior experience I take these relative estimates (story points) and create a rough schedule for when major milestones of the project will be complete.

3) Within these milestones we run 2-week iterations. The customer is involved in setting the approval criteria and whether or not the story has been approved. A simple burn down chart shows the customer how close we are to meeting the launch goal.

4) Often time during the approval sessions the customer will request a change because the feature did not turn out how he expected it (even though it met his original approval criteria). At this time you generate a new story with a new estimate. You can also adjust your milestone dates appropriately. This then puts the ball back into the customers court:

• Often times they realize their change request isn’t worth it (they’d have to get approval from their boss) and we’ll kill the new feature
• Sometimes it is important so we’ll delay the due date to get the feature in
• And finally, there’s always the option to kill another not so important feature that will take an equivalent amount of time.

The key is not to run away from change requests, but to establish that every change request has consequences on the product. There’s no such thing as a free lunch.