“Why is this team ignoring parts of my requirements?!” If you’ve ever struggled with developers skipping or deprioritizing certain requirements, the problem might not be them—it might be your choice of words.
In Lesson 1, we covered the importance of writing specs.
In Lesson 2, we established that all specs must live in a single source of truth.
Lesson 3 covered consistent naming conventions to avoid confusion.
Now, we’re tackling an issue that is often overlooked but critically important—choosing the right verb in your requirements.
Prefer watching instead of reading? Watch the full lesson here:
When writing requirements, inconsistent verbs lead to misinterpretation. If you use different verbs like “must,” “should,” or “shall” interchangeably, your team might assume different priorities where none were intended.
Here’s why choosing a single verb is critical:
1️⃣ Prevents teams from making assumptions about priority.
2️⃣ Ensures all requirements are treated equally unless explicitly stated otherwise.
3️⃣ Creates clarity and removes ambiguity in requirement interpretation.
4️⃣ Reduces miscommunication and prevents critical features from being deprioritized.
🚨 Biggest lesson: Your choice of verb dictates execution—be consistent.
💡 Pro Tip: Pick a single verb and use it religiously across all requirements. My recommendation? Use “shall” for all requirements.
When I worked with an external development team, I kept noticing that some of my requirements weren’t implemented. For weeks, I assumed it was due to workload, sprint planning, or prioritization issues. But then I had a conversation with the project manager that changed everything.
Here’s what happened:
🔹 I wrote two requirements:
🔹 I assumed both would be implemented. But only the first one was.
🔹 The project manager explained: “You wrote ‘must’ for one and ‘should’ for the other. ‘Should’ implied optional, so we ignored it.”
At that moment, I realized: My inconsistency caused the issue, not them. I had unknowingly introduced an implied priority system just by using different verbs.
🔥 Lesson Learned: If I had used “shall” consistently, there would have been no ambiguity, and the team would have known everything needed to be done.
Want to avoid having your requirements misinterpreted? Follow this simple action plan:
1️⃣ Pick a single verb (e.g., “shall”) and use it for every requirement.
2️⃣ If priority needs to be indicated, use a separate column, tag, or attribute—not different verbs.
3️⃣ Review your current specs and replace inconsistent verbs to ensure clarity.
📌 Bonus Challenge: Look at your latest specs—how many different verbs do you use? Standardize them today!
📌 Key takeaway: Inconsistent verbs lead to misinterpretation and lost requirements. Standardizing your verbs ensures every requirement is understood and executed properly.
🎯 Next Lesson: One requirement = One testable thing
💡 Want to write better specs? Get access to more lessons and tools.
👉 Join the SwipeSpec Waiting List (Free Early Access!)
🎬 Watch the Next Lesson → One requirement = One testable thing
📩 Subscribe to get notified about new lessons!