Are you tired of having to re-explain your original request to your product and engineering team, when they didn’t quite get it right the first time? (or the second time?)

At Devblock, we’ve designed, implemented, and launched hundreds of products throughout our history. This experience has underscored the immense value of establishing effective ways of working, benefiting everyone involved in product creation and delivery. At first glance, following processes might seem like a burden or something to be avoided, but it’s actually inherent in everything we do – just sometimes subtly and not highly formalized. Tailoring these processes is essential for every organization to discover what works best for them. One of the processes that we’ve found most valuable in eliminating re-work is always including the reason for the requirements we write.

A Common Oversight

During a recent consulting session, we observed that one of our clients was not capturing the “why” behind each story or task. This oversight is surprisingly common. Many teams write user stories that simply state: “As a user, I want X, Y, Z.” However, they often omit a crucial element – the “so that” clause. Adding this clause just means adding “… so that ___” to the end of the user story, so that the person reading the story knows the motivation for the functionality and can therefore perform their work related to this story far more effectively. There are some great resources that support this, such as these on Mountain Goat Software and Atlassian.

While we acknowledge there is no “silver bullet format” to specifying your requirements, we’ve learned to always include the “why” on the stories we write for several key reasons.

The Importance of Context

Excluding the reason for a requirement may seem like a minor issue at first, but crafting stories that encompass the core aspects of “who, what, and why” dramatically improves the entire product engineering process. Writing stories this way may seem daunting, but once you choose to adopt this practice and have given it a go for a week or two, it will start to feel natural, and the long-term benefits are undeniable:

1. Clients will be happy to see demos that match their expectations, rather than having to repeatedly say “that’s not what I meant!” and attempt to re-explain their intent granularly.
2. Product Managers gain clarity and can better prioritize by comparing the justifications of various stories. Sometimes, this process leads to realizing that a story needs refinement – helping avoid costly directional missteps.
3. Business Analysts can interpret stories more accurately, focusing on relevant details rather than tangential criteria.
4. Developers benefit from clear reasons behind stories, minimizing assumptions and ensuring implementations align closely with original intentions.
5. Testers and QA Teams move beyond simple verification of acceptance criteria. They can critically analyze functionalities from multiple perspectives to identify potential flaws more effectively.
6. DevOps can plan more efficiently for capacity, security, and robustness by understanding the purpose behind features. This alignment with business goals transforms potential friction points into opportunities for collaboration and solution development.

Cultivating a Purpose-Driven Team

Understanding the reason behind their tasks not only equips team members with essential context but also instills a sense of purpose and motivation. After all, aren’t we all seeking to be contributors on teams of aligned and passionate members, to build great things?

A Few Examples

Here are some examples for hypothetical scenarios (some are based in reality, naturally) just to illustrate:

1. As a marketing manager, I want to add a “Preferred Contact Method” dropdown field to the customer registration form so that I can collect customer preferences to tailor our outreach strategies.
2. As a customer, I want the registration form to validate my email address for proper format and domain so that I know immediately if there is a mistake and don’t miss important communications.
3. As a consumer, I want the “Shipping Address” field to appear only if I select “Ship to a different address?” so that the form is easier and faster to fill out in certain scenarios.
4. As a support team member, I want the “Priority” field on the support request form to default to “Medium” so that I can quickly identify high-priority issues without needing to manually adjust lower-priority requests.
5. As a legal department representative, I want the registration “Terms and Conditions Agreement” checkbox to be mandatory on the signup form so that we can reduce legal risk.