What do contracts like Statement of Works and requirements have in common? 🤔
Ambiguity = pain.
I’m writing a follow-up from my previous post on Acceptance Criteria.
Example User Story:
As a customer, I want to be able to browse a wide variety of bikes on the app, so I can explore different options and find the one that best suits my needs and preferences.
Example Acceptance Criteria
GIVEN that the user is logged into the app on their mobile phone
WHEN they click on the bike category,
THEN they should be presented with a variety of bike models for exploration.
In the above examples, my discovery masterclass student was presenting a user story for a fictional company who was building a sales app.
Which word/phrase do you think invites ambiguity and could potentially cause an issue when the system’s built and ready for testing?
It’s “variety”.
My feedback was that this be removed and replaced with more precise phrase because ‘variety’ might need to pull information from an external system, which signals that intergration will be needed.
This needs to be tightened up in a way that helps
– the client understand what they’re going to get
– the development team know what they’re building (and how)
– the test team know how to test it and what negative scenarios to create
This is for consulting-led projects where a #SalesforcePartner is helping to implement #Salesforce for a client.
When an internal Centre of Excellence (or the internal Salesforce admin and team) or a software company is running in a more agile manner, then requirements or user stories are likely to be groomed repeatedly by different parties until it’s ready to go into sprint.
Consulting project teams who aren’t running true agile with flexible requirements need to be a lot more precise and clearer.
For us – SOW and Acceptance Criteria are contractually agreed Things We Must FulFil For Our Customers.
Deviating from that requires strong change control procedures.
(Commercial model for agile projects are different – and warrant a post of its own.)
I’ve seen too many RED projects happen because requirements were wooley and SOW littered with vague fluffy clouds of not-sure and maybes.
It gets so much trickier when the lawyers get involved 😖
And that’s why I’ve designed my consulting masterclasses for partners to focus on how to ensure we correctly understand our clients, and document those requirements clearly and properly so that we don’t get into arguments during UAT.
Have you seen projects that could have been saved if language was clearer?
What other ‘fluffy’ words have you seen in requirements or SOWs that have been ☠?
I’ll start.
Liberal use of ‘TBD’ in a solution document for a Fixed Price SOW.
😱😱😱😱😱😱😱😱😱😱
ps: image below is from my book Salesforce Discovery 101 that includes what a Statement of Works should/shouldn’t have and how it impacts projects.
Shameless plug: Get yours now at your nearest Amazon store! 😁
#SorryNotSorry 🤭
