The Emotional Roller Coaster of Changing Requirements
Last-minute changes disrupt flow and trigger emotions such as anger, frustration, and anxiety.
This is the latest issue of my newsletter. Each week I cover research, opinion, or practice in the field of developer productivity and experience.
This week I read The Emotional Roller Coaster of Responding to Requirements Changes in Software Engineering, a recent paper by researchers from the University of Auckland. The study aimed to understand how developers react emotionally to changing requirements at different stages of development.
My summary of the paper
The researchers hypothesized that unexpected or late Requirements Changes (RCs) impact more than just the cost, quality, or scheduled delivery of projects — they also affect developers' emotional states. Emotions are important because they act as behavioral motivators, and have “direct linkages to cognition, productivity, and decision-making.” By studying the emotional experience of requirements changes, the researchers sought to help engineering teams make more informed decisions about whether to introduce or accept changes.
Requirements changes (RCs) are defined in this study as “additions, modifications, and deletions of functional or non-functional requirements.”
This study was conducted through a world-wide survey of software practitioners. The survey included two core components: it used the Job-related Affective Well-being Scale (JAWS) to assess people’s emotional reactions to their job during the past 30 days. It also included a set of open-ended questions to capture participants’ emotions when handling RCs in their work and query about the different circumstances when they feel these emotions. To analyze survey data, the researchers used a combined approach of statistical analysis, JAWS, and Socio-Technical Grounded Theory (STGT).
Here’s what the study found:
What triggers emotions
The researchers explored what events trigger emotional responses with regards to requirements changes. The leading trigger was the point of introduction, or when the change was introduced in the development process. Other triggers identified included the frequency of introduction, impact, definition, status, severity, and how challenging the change is. These events cause developers to feel fatigued, frustrated, and angry.
The researchers also found that developers are anxious or frustrated when:
the project has begun and requirements seem are not yet fully settled in,
RCs are introduced when developers are already in the midst of the implementation or testing phases,
a significant amount of interdependencies exist with the RC, or
the deadline is approaching.
Use time as a lever to regulate emotions
Time is a lever that teams can use to regulate the emotional responses caused by changes in requirements. Developers care about having a project remain on schedule; when a change must be introduced, consider whether the changes will still allow developers enough time to complete the work on schedule and if not whether the schedule can be changed.
Last minute RCs were found to be a common occurrence that disrupts flow and triggers emotions such as anger, anxiety, frustration, and fatigue. Conversely, when the RC fits the timeline (i.e., when we extend the timeline), this triggers “high” emotions such as feeling satisfied and energized.
Recommendations for leaders
Apart from extending timelines when possible, the researchers also recommend that managers prioritize developers’ emotional well-being by being more empathetic in situations surrounding changing requirements.
Additionally, a decision guide is presented that may help decide when to introduce or accept a requirements change:
Final thoughts
There is a growing body of research on developer emotions and their impact on outcomes such as productivity, creativity, and work quality. This trend is beneficial because it shows the importance of problems that developers know exist but that are harder to quantify, like changing requirements.
This paper may also be a useful conversation starter for teams experiencing friction between product and engineering that are specifically seeing frustration and rework due to product requirements lacking context.
That’s it for this week! Share your thoughts and feedback anytime by replying to this email.
If this email was forwarded to you, subscribe here so you don’t miss any future posts:
-Abi