Conflicting Requirements

Conflicting requirements are when a customer asks you to make the system do two things you can't possibly do at the same time- fat client AND and HTML server [somebody put a better example in, please].

The conventional wisdom is that conflicting requirements are a sign of big trouble. You couldn't possibly satisfy them both, so the customer can't possibly be satisfied.

Consider AnalyzingXpWithOptionsPricing for a moment. You can buy a BestOfOption? that allows you to exercise one of two options, but not both. They are useful when only a combination of market moves (falling oil and a rising dollar, for example) would prove ruinous. The value of a BestOfOption? is calculated by examining the correlation of the prices of the underlying instruments. If the prices are perfectly correlated, then the value is the same as for a single option. As the prices become less and less correlated, the value goes up. The value is highest when the prices are perfectly negatively correlated.

The PlanningGame produces a plan that acts like a BestOfOption?. You know everything the customer wants won't fit into this release. They get to choose what goes in, and they get to change their minds. From our analogy, we would expect conflicting requirements to be the most valuable possible situation (as long as we don't try to implement both stories at the same time). -- KentBeck and MaroanMaizar

[From WhenIsXpNotAppropriate]

"Pure ExtremeProgramming might not be optimal when...

You have Conflicting User Requirements:: "Business absolutely refuses to play their part in the PlanningGame, and punishes you for nominating someone to play Business until they get a clue."

If you were not doing ExtremeProgramming, how would you address this problem?

Here are some approaches to resolving conflicting user requirements:

Get the conflicting users to sit down and talk with each other. (Yes -- this, by itself, may be enough to solve the problem.)
Find a single person to "represent the interests" of the conflicting parties: This can be a person they all respect, or a person who has power and authority over them (IE: a high level manager, or their representative).
Propose a set of rules for resolving conflicting agendas, get them to approve the rules, and then apply the rules.
Use a democratic "change control review board," where each interested party gets to vote, and exercise political influence.
Separate Budgets: If all else fails, give each group their own "budget" of function points / perfect man weeks (or whatever) to "spend" on each iteration.

One area of concern with XP is the OnsiteCustomer. In many situations, commercial development for example, there are numerous customer groups, each of which must be satisfied to some degree. This breaks down the UserStory requirements gathering approach, the PlanningGame, and customer written AcceptanceTests. There are alternate methods of requirements gathering, which I think would work with the remainder of the XP practices, but there would not be the clear dividing line between business and development proposed in pure XP (I tend to favor breaking down the dividing line). -- WayneMack

To me, one of the key ideas of the OnsiteCustomer is that these decisions and trade-offs will have to be made, and will be made, and letting it be an unconscious process is a bad idea. If the business units flat out refuse to do their job and steer the project (isn't that why they're business?), then the dev team can elect one of their own to make the decisions that the OnsiteCustomer needs to make, and to document them as a business process. The difficulty is protecting that person--if your business is already this dysfunctional, then you have a good chance of project failure for non-technical reasons, and a good chance of turning said dev team member into the scapegoat. Documenting what you're doing may help defend this--you can show higher ups what decisions were being made, the fact that a developer was stuck doing the job, and noting that firing your developer for managing the business side of the project badly is like firing your chef for mopping the floor poorly. --RobMandeville

I haven't seen any reason to break that dividing line. In fact, in the scenario you mentioned, I'd strengthen it. There can be as many customer groups as anyone wishes and business can gather requirements in whatever way that they want to, but if they do the PlanningGame with developers and show a single face to the developers, the business/development split will be intact and workable. -- MichaelFeathers

Who is this amorphous "They," and how do you get them to present a consolidated face? Each user group is only going to and be able to express its own interests. It really falls back to development to go out and gather requirements and balance competing interests among different user segments. This remains moe of my biggest qualms about XP; in most of my development experience, there simply isn't this unified decision making user entity. I don't think the development team can shrug off the responsibility for requirements definition and prioritization. -- WayneMack

Several years ago I was leading a project which was to produce software for two disjoint user groups with competing interests. I'd say that about a third of our time was spent acting as mediators and playing little games to make sure that everyone was happy. Over the course of development, one person who had background in the technical areas of both of the groups ended up being someone who both groups respected. Today, I wish I had checked around and seen if she could have become our customer. In teams I've worked with since, having a customer with a single voice has changed the whole tenor of development. The Programmers can actually code rather than act as perpetual negotiators. It is far less distracting. -- MichaelFeathers

When I encounter conflicting or confused user requirements or priorities, I impose a traditional change control process:

Write down every last thing the user asks you to do; both bug fixes and enhancements. People can get very political when things are done entirely through word of mouth; they, being the customer are "always right," so you'll always lose.
Number and name the tasks, so you can talk about them easily. Like, 'oh, you're talking about the 'automated interface to system X." -- number 28 on the spreadsheet.' (Or go ahead and write them on cards, if that's your thing. ;-)
Propose a fairly objective set of severity rankings, like "1 = system fails and loses data, ...to... 5 = minor inconvenience, with workaround," and get something like it accepted. (Or just do it, and see who objects.)
Demand that the users give priority rankings to the items they asked you to do. Give them a set of rankings, like A,B,C or 1 to 5 to work with.
Inform the users that if they can't make up their minds, you will proceed to fix problems from (your assessment of) most severe to least, in whatever order you find most convenient. If they want the stories implemented in some other order, they'll have to play your game. ;->

This doesn't actually solve all the problems, but it kills the most severe political problems right off, and gives people a framework within which people can hold productive discussions. (Anyone who tries to stop you will have to explain why fixing severe problems that crash the system and corrupt business data is not an important problem that should be addressed right away.) -- JeffGrigg

To me this seems like the perfect example of why we need RequirementsMiranda. "If you can not afford a set of requirements one will be appointed to you."

CategoryPlanning