The use case model diagram was generated from the interpretation of the set of user stories. This diagram instantly reveals insight into many quality aspects of the set of user stories that are just not visible in requirements repositories such as Trello, Jira, Azure DevOPs. This diagram reveals, the logical relationship between user stories. This diagram helps you to determine if you have the right requirements?
From the functional intents determined by ScopeMaster a suggested class diagram of all the probable classes, and their methods is determined from the text of the user stories. This can help developers understand what data they need to consider and how it might be stored and handled. This is not a definitive class diagram but a very useful starting point. This diagram helps to determine how to organise and structure the data to meet the requirements?
Determining the Backlog Size
For all teams, all projects, user stories vary in size and the effort to deliver them. This variability can be very high. ScopeMaster was designed from the outset to automate functional sizing of written software requirements. This means it was designed to eliminate or reduce the administrative work of reading requirements to determine a formal functional size estimate of the software that they describe. Functional size is a technology agnostic, user-oriented indicator of magnitude. ScopeMaster estimates functional size in the two main ISO standards for sizing software, namely COSMIC Function Points and IFPUG Function Points. We recommend the former as it is more suited to modern software architectures and handles incomplete requirements better. ScopeMaster estimates the functional size of all the stories in your entire backlog in a matter of minutes, saving the team from wasting time on valueless discussions about story points or T-shirt sizing.
In just under 3 minutes ScopeMaster identified hundreds of problems with the user stories.
51 of the 98 user stories had ambiguous functional meaning, which if left unresolved would lead to bugs. 51 defects identified.
Missing Basic Security User stories
There was no mention of login, authenticate, authorize, permission or logout throughout the user stories. This is evidently an important omission. We typically expect this to require at least several user stories. (although the “forgotten password” story is there). 5 defects identified:
• Validate email
• Change password
• And then with each role sensitive user story there woul need to be a role and/or permissions check
The original set of user stories did not completely describe the required functionality.
Inconsistent terms for Users/Personas
ScopeMaster identified 26 potential user types. It is likely that there are actually only 10 distinct personas. 16 defects identified.
Inconsistent terms for Users/Personas
Similarly ScopeMaster identified 41 potential object types, whereas there are probably only about 25-30. 16 defects identified.
Completeness of Data Maintenance (CRUD analysis)
For each valid Object type there should be at least 1 function for each CRUD event. After eliminating the redundant object types, this leads to about 80 missing functional user stories. 80 defects identified.
The Use Case Model Diagram revealed further missing requirements based on role/personas. We estimate at least 1 or 2 per user type. 10 defects identified
ScopeMaster identified that only 58 of the 98 have used the phrase “so that”, however all but 3 do include the term “so”. 3- 40 defects identified
Furthermore, ScopeMaster’s Non-Functional Requirement detection identified that there are several relevant categories of NFRs that were not mentioned in this set of user stories: accessibility, auditability, observability. 3 Defects identified
Quality Results Summary
In just 3 minutes, ScopeMaster identified 211 likely problems (97 + 114) with these user stories. It has also inferred via the CRUD analysis that only half the probable necessary user stories are actually listed. (this example set of user stories may have been deliberately trimmed before publishing).
Furthermore ScopeMaster generated over 140 essential test scenarios, which will help speed up the functional testing initiative, once the functionality has been created.
The purpose of this exercise was not to criticise the example user stories but to highlight the value of using ScopeMaster on any set of user stories.
We welcome any comments by the folks at Mountain Goat.
From this exercise, we can see that ScopeMaster performs a valuable job on this example set of user stories. It has:
- Revealed over 200 problems that can be readily resolved before inadvertently becoming the cause of rework.
- Revealed missing scope
- Revealed a potential data design
- Produced usable foundation test scenarios for each user story, including both positive and negatives tests.
- Estimated the functional size of each story, (including the missing ones) in ISO standards of functional size.
All this adds up to a substantial amount of useful, insightful, shift-left work that helps to bring certainty to the scope and reduce risk of any software project.
It would be great to hear from Mike Cohn or anyone who worked on the ScrumAlliance website of their experience of using these user stories and about their thoughts on ScopeMaster’s analysis. So far nobody from his team has been available to comment.