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.