The Fundamental Attribution Error and Poorly-Written User Stories
Keith is a Software Engineering Principal Member of Technical Staff in the Salesforce Database Cloud organization.
The fundamental attribution error is our tendency to reach conclusions about the cause of somebody’s behavior being due to internal factors such as personality and to discount external factors that may actually play the greater role. The book Switch: How To Change Things When Change Is Hard by Chip and Dan Heath describes the fundamental attribution error as one of the obstacles to be overcome in effectively bringing about change in others and in ourselves.
This notion of taking the time to consider whether a perceived personal problem actually has a situational cause is worth considering in many contexts.
For instance, teams that practice Scrum and Extreme Programming often encounter a problem that may mistakenly be ascribed to the team members themselves, but may actually have its roots in the environment that team is working in. It is the problem of poorly-written user stories.
Poorly-written stories — that’s got to be a people problem, right?
What’s stopping your team from writing their user stories well and how could you influence them to change this behavior? The book Influencer: The New Science of Leading Change by Joseph Grenny et al. breaks influence down into six sources:
- Personal Motivation
- Personal Ability
- Structural Motivation
- Structural Ability
- Social Motivation
- Social Ability
Education
While personal motivation is important, it is not the only source of influence we have at our disposal. Let’s consider the other five. First, we have personal ability. This leads to the question of whether the team members have been educated in how to write stories well. Have you taken the time to teach the team about the concept of INVEST criteria as originally proposed by Bill Wake in INVEST in Good Stories, and SMART Tasks and popularized by Mike Cohn? In his blog post, Wake stated that the acronym “INVEST” can remind you that good stories are:
- I — Independent
- N — Negotiable
- V — Valuable
- E — Estimable
- S — Small
- T — Testable
Adequate Time
Structural motivation is about how your organization rewards behaviors and results. If your organization prioritizes churning out code and makes user stories an afterthought, this will turn up in the way new features are requested. If developers are being told, “Go write the code for feature X,” and not, “Let’s get together with the customer to talk about a story or set of stories,” you may have a problem with structural motivation. What is your organization doing to ensure adequate time for story authors to give the practice of story-writing the necessary time investment?
Tooling Support
Next is structural ability, which Grenny et al. break down into four subcategories:
- Space
- Data
- Cues
- Tools
The two most applicable here are cues and tools. Assuming your team enters stories into an issue-tracking program like Jira, how much does the tool encourage good story writing? Are there templates or reminders (cues) of the INVEST criteria built into the tool?
How well does the software get out of the developer’s way? If the issue-tracking software makes entering stories a pain, story authors are going to dread writing stories and not put as much energy into it. On the other hand, when the software gets out of the way, it can encourage a different way of thinking about story writing — not as a chore that you do because your Product Owner, your manager, or your Scrum Master said to, but as a convenient way of getting your thoughts into writing so that that they trigger your memories of the story conversations you had with customers.
Peer Pressure
Lastly, we come to social motivation and ability, which, among other things, includes the influence and support of one’s peers. When a new developer joins a team, they look to their teammates to learn the way things are to be done. If their teammates are all writing stories that go, “As a developer, I want to deliver feature X,” then that is what the new developer is going to do, too. In a way, this can be difficult to rectify because once you’re past the tipping point in which more than half the team writes stories in this way, you’ll need a concerted effort not only to make progress but to keep things from sliding further. In the case of new team members, ensuring that they are mentored by those team members that practice good story-writing habits is crucial.
Verdict — People or Situation Problem?
There is no one right answer. Every team is different. But I hope I have provided a way to reframe the problem and explore more possible causes and more ways to influence the team to reach a better state.
Follow us on Twitter: @SalesforceEng
Want to work with us? Salesforce Eng Jobs
