10x - 100x Faster
1,000 times more thorough
On average we run about 1000 tests per user story. This is a combination of static and dynamic tests. This is a level of scrutiny not normal achieved with manual story reviews.
Want to know more? Read the details on the kind of testing performed by ScopeMaster.
ScopeMaster provides software requirements analytics that help software delivery teams to deliver software projects faster and with more certainty.
If it can be misinterpreted, it will be
If a user story can be interpreted differently by the key readers (author, user, tester, developer) then it is likely that one of them will be working to the wrong understanding, generating waste and rework. It is very important to nip these ambiguities in the bud.
125 Reasons To Test User Stories
The ratio of words in a user story to the number of coding tokens we typically see is 1:125. A 12 word user story would probably end up becoming about 1,500 coding tokens, approximately 300 lines of code. So, for every minute spent fixing an ambiguous word in a user story will probably save 125 minutes in coding. Now that’s time well spent!
Extreme Left Testing
User story testing may sound like a strange idea, but it’s not. In fact its one of the most productive things that you can do on a software project. It’s the epitome of extreme left testing. If you want to become a more successful product owner, start testing those stories as early as possible. User stories are an expression of requirements on agile software endeavours. Like other software development deliverables, they too are prone to errors. The particular challenges with user stories is that they can very easily be misinterpreted, which can lead to a lot of wasted time and effort. In fact they are more likely to be misinterpreted than not.
How to test user stories
So how do we do it? Let us start with the basics. What is a business software requirement?:
A real business requirement (or capability) is “what must be delivered to provide value to the business” (Robin Goldsmith). User stories are the discrete functional requirements that make up that capability.
What if you don’t test your user stories?
Poor user stories (or poor requirements ) are the root cause of 35% of production defects (Accenture, 2021). A requirements problem that is not resolved until later phases of the development/deployment may cost 75-1,000 times more to fix than if it was fixed before coding starts.
Need for Discipline, to Reduce Ambiguity
When we write code, we follow disciplines to improve readability, reduce complexity, increase re-use and much more. (For more on this, read the excellent Code Complete, by Steve McConnell). Writing user stories also warrants such discipline, especially to minimise ambiguity, inconsistency and complexity. In fact a good user story can be rather boring as it is unambiguous. Be prepared to adjust how you write user stories, adopt consistency and discipline to drive out ambiguities. Fortunately ScopeMaster will help you learn as you go.
Related tools
Jsonlint is an online tool for testing the syntax of a json file
HTML Validator is an online tool for testing HTML syntax.
