Stories, requirements, and language

The negotiation between client and team on what gets delivered is the toughest aspect of software development that I’ve encountered.  Something that’s eased this aspect for me is adopting User Stories and abandoning “Function Requirements” and “Feature Requests”.  I’m reading through Mike Cohn’s User Stories Applied to gain a better understanding of the concept.  In the book, Mike Cohn shares a quote from a customer of his:

You built exactly what I asked for but it’s not what I want.

I just love this quote, as it’s what I’ve run into dozens of times when I used requirements and feature requests to define customer needs.  Mike has a great article on the advantages of user stories as requirements.

For me, the difference between the three is the underlying meanings of the words will have with the clients.  It’s amazing how much subtle variations in the language we use impacts assumptions, understandings and relationships.

Negotiation and conflict

I’ve used three types of artifacts in my career so far to deal with customer needs:

  • Feature requests
  • Function requirements
  • User stories

Ignoring the semantic definition of all three, suppose each of these pointed to the same artifact: a story card.  This story card has something similar to this on the front:

A job seeker can edit their resume

Now all three definitions are on the same playing field and point to the exact same project artifact.  Do the definitions still all hold the same value?  Unfortunately not, as language and meaning significantly shape a person’s interpretation of a concept.

Asking and denying

Take the words “Feature Requests”.  What kind of contract does this imply between the customer and the team?  What kinds of interactions will this lead to?  Requests are questions, or “asks”.  I am requesting that a job seeker can edit the resume.  How does the team respond?  Are they now in control of what gets developed or not?

When you label something a “Request”, it implies the customer is asking for a feature.  The team accepts or denies this request.  Now the contract between the customer and the team is a contentious and strained.

Whether or not this is what happens in reality is irrelevant; the words attributed to the artifact enforce a certain kind of negative contract between customer and team.  Trying to fight the underlying meaning of the words will be like swimming against the current.  It’s possible, but exhausting and expensive.

Asking for features puts the customer in a bit of a jam.  It’s now their responsibility to convince the team to accept their feature requests, even though the customer has the best knowledge of what has the highest priority.  Developing software is hard enough, we shouldn’t make it more difficult by enforcing a subservient relationship between client and team through our language.

Requirements and fear

Swinging the pendulum the other direction are “Functional Requirements”.  Now take the word “requirements” by itself and its meaning.  Requirements imply something needs to be done.  If you don’t do what is required of you, you have failed.

In the context of software development, “Functional Requirements” puts quite a bit of strain on the team.  If they deliver 99% of the requirements but miss one, they’ve failed as they haven’t done everything that the customer said was required.

Teams may deal with this by assigning priorities to requirements, but that’s putting lipstick on a pig.  Something that is less required than something else doesn’t mean it isn’t required.  Not doing the lower priority requirement still means you missed a requirement.

Putting requirements in contracts is also hazardous, as customers tend to focus on what was missed.  Even if the software moved in a different direction, the customer looks at the original requirements and sees items missing.  Just calling them “requirements” implies that they are absolutely necessary for success.  Because the team called a customer need a “Requirement”, the customer believes success is dependent on that need being fulfilled.

In the end, an acrimonious relationship between customer and team will result.  The team will fight as much as possible to limit the number of requirements in the contract for fear of not delivering them.  The customer can’t berate you for missing a requirement that wasn’t in the contract, but they’ll resent you for not letting them put it in the contract in the first place.

The fear and resentment between the two parties can absolutely kill productivity, and success will likely be accidental.

Getting the language right

Even if all three “customer need” definitions pointed to the same concept, the words attributed to the concept will shape the underlying contract and relationship between customer and team.  With User Stories, the team (which now includes the customer) is free to generate as many stories as they like.  The main negotiation that takes place are the priorities for the stories before each iteration.

That’s where the “Customer collaboration over contract negotiation” piece comes into play.  The team has one goal: customer success.  Anything that gets in the way of that success, including language, should be scrutinized, debated, and acted upon.  Since language and definitions shape understanding and meaning, it’s critical to get the language right, even if the underlying concepts are the same.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in Agile. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Great post Jimmy. “Functional requirements” being used as the basis for contracts is something that is hitting home for me right now. That whole concept seems to be so in-grained in the culture at many shops that everyone is afraid to manage projects in a different way, even if it is probably better.

    What would you say is the best way to start piecemealing these fundamental changes into an organization? Especially when the amount of influence you have over how projects are managed is minimal?

  • At my company we still need “requirements” for some peer-review process and for some high-level stuff that the folks at “corporate” require us to have and something to do with auditing. We also have to be able to link test cases to requirements for something to do with risk management. The point is that we can’t ever get rid of requirements (or at least for the next few years, which may as well be forever in the software world).

    The way we’ve handled this with stories is that each requirement has one or more stories associated with it. We then can write test cases for each story and then we develop against the stories and run tests and log bugs (how to log bugs in agile is a totally different discussion that I will not go into here).

    This way, we can go from test case to story and then from story to requirement. This makes the upper-upper management and the auditors happy but still allows us to be more Agile. As the requirements change or, more accurately, our understanding of the requirements changes, we can write more stories or modify existing stories to more accurately reflect what the requirement is for. I hope to continue this trend away from requirements but it’s going to take a long time before our company fundamentally changes its “requirements culture.”

  • Excellent post! I guess a rose by any other name is _not_ the same.