Refining User Stories
Refining user stories is the process of improving, splitting and clarifying each user story. The detail and clarity of each user story should be revisited. Backlog grooming is a term that generally refers to the higher level process of prioritising user stories. Both refinement (clarifying) and grooming (prioritising) are important steps in achieving good quality requirements. The former ensures that user gets what they want and the latter deals with sequencing to suit both business need and development team efficiency. In this article we will focus here on the refinement of user stories, leaving the prioritisation to separate article.
Purpose of User Stories
The purpose of user stories is to communicate, to ensure that needs of the user is correctly expressed in language that a developer and tester can fully and consistently understand. The user stories need to be user-oriented, simple, clear, unambiguous and consistent, with nothing missing. By refining your stories, you will eliminate many requirements defects that are often not found until well after the design and development work has started. Refining user stories with ScopeMaster is typically 10-20 times faster than doing so manually.
User Stories or Requirements
Are user stories and requirements the same thing? Some agile purists will explain that user stories are reminders of conversations and therefore not requirements. We have observed however, that for most teams, the user stories are treated as the requirements, and so we do the same. Requirements or user stories are essentially an expression of capabilities that the users need from the software, to ensure clear and consistent communication to the team. Note that User stories (or requirements) do not include technical tasks or project constraints. Hereafter we will use the terms requirement and user story interchangeably.
Defects in User Stories are Inevitable
Writing requirements or user stories is the same as any other knowledge work – we make mistakes as we go. Even if we are careful, mistakes will happen, they are inevitable. Furthermore we generally write them in English which is an incredibly subtle language where every word can be understood in different ways by readers. So even if we think we have written them well, it is quite probable that readers of them will reach a slightly different understanding. If two readers of user story can reach a different understanding – then you have a defect. A defect in a user story or requirement will lead to the wrong software being built.
Cost of Defects in User Stories or Requirements
Understanding the cost of quality is a very important topic as it can help us appreciate why requirements quality really matters. A requirements defect that is not resolved before development, will lead to a bug. That is an unavoidable fact. Many requirements problems get spotted during development. But not all of them. Let us consider what is the impact if we don’t find and fix that mistake until later in the software development lifecycle (SDLC). If the mistake is found during development, then we may have to stop development, check what the correct requirement is, then redesign it and rewrite the code. This takes time and will disrupt and delay progress. Depending on the nature and severity of the requirement defect, this can lead to major rework (different design, different architecture). It can delay projects and lead to significant cost increases.
Now let us consider an even more severe situation where a defect in a requirement is not noticed until after the code reaches production. This can have even more severe consequences. The software may be doing the wrong thing and be causing harm to users or the business. This can have a catastrophic impact.
Cost of Recovering from Defects in Requirements
If a defect caused by poor requirements is found in production, and it is a severe one, there are two categories of cost: internal and external.
Internal Costs
- The extra work to change the software to work correctly
- The extra work to alter data that has been incorrectly handled due to the fault
- The opportunity cost of diverting staff to fixing this defect vs doing other useful work
External Costs
- Consequential cost to the users or beneficiaries of the software, caused by the bug
- Compensation to the users who suffered that bug
- Additional work by non-software staff to handle the incident/impact on users until the bug can be fixed
- Reputational Damage to an Organisation
In most cases, software project teams underestimate the cost of poor requirements. If you’d like to learn more about this topic, I recommend this excellent book “The Economics of Software Quality”
Automated Requirements QA
ScopeMaster takes the work of requirements quality assurance to a new level. ScopeMaster helps to accelerate the work of requirements quality improvement and user story refinement.
ScopeMaster will automate the finding and accelerate your fixing of many requirements defects to help ensure that your requirements or user stories are:
- Clear
- Concise
- Consistent
- Complete
- Testable
- Sizeable
- Unique
- User oriented
- Design free
The one important attribute that ScopeMaster cannot automate is to detect if you actually need the requirement, is it valuable? This you’ll have to resolve yourself, but ScopeMaster frees up so much of your time, you’ll have the capacity to consider the real value of each requirement.
Learn more about automated backlog refinement
What are Good Requirements?
We have established that poor requirements are harmful, costly, wasteful and in some cases, even dangerous. So how do we go about writing good requirements? How do we know if we have good requirements? How can we spot problems in requirements? There are some universal ingredients to good requirements that we will describe, that will help you:
User-oriented
All requirements must be expressed in terms of what a user needs. They may subsequently be broken into developer tasks, but a version of the requirement must first be expressed in relation to the user need so that we can be certain that what gets developed will meet the user’s need.
Clear and Unambiguous
A requirement should not be easily misunderstood by readers. This is perhaps the hardest dimension to ensure. It means that a requirement should describe clear functionality that a user needs to perform. Two readers of the same requirement should reach the same general understanding of what data needs to be handled as part of the requirement.
Concise
Requirements should be concise. A requirement does not need to be verbose, nor use flowery elegant language.
Consistent
A set of requirements should use consistent terms for types of user e.g. administrator. A set of requirements should also use consistent terms of types of data (Object types)
Complete
A requirement should be complete in itself (describe all the functional steps needed for that user capability). Also, a set of requirements should be complete, describing all the functionality needed to maintain all the data within the system. For this, CRUD analysis is most helpful.
Sizeable
If a user requirement is not functionally sizeable (i.e. measurable in COSMIC function points) then it is almost certainly lacking in quality if one of the other aspects in this list. Which is why we consider that the ability to size in CFP is an excellent test of requirement clarity and quality. Nb. technical tasks and non-functional requirements are not sizeable in this way. Technical tasks are generally sized in staff hours. Non-functional sizing is an unresolved problem, although there are some recommendations (in a separate article).
Testable
Testers must be able to determine how to test that a requirement has been met. Therefore the requirement must be written such that it can be tested. One of the best ways of ensuring that that requirement is testable is to ensure that it clearly describes functional intent. (For this we recommend COSMIC sizing)
Unique
We don’t want a set of requirements to contain duplicate content or duplicate functionality. (This is perhaps one of the least significant quality problems of requirements.)
Design-free
User stories should not contain any detail about how a capability should be implemented. A user story is not a placeholder for design details. You can break down the work to implement a user stories into technical tasks, but these are not user stories.
Valuable
Every user story must provide value to the user or stakeholder, otherwise it should not be built. The value should be expressed in terms that the user (not the developer) will recognise.
That is our recommended list of 10 attributes of good user stories or software requirements. It applies in all situations. Some requirements experts will rightly argue that it does not go far enough. That is true, there are certain situations where requirements should meet even higher standards than what we have described here. What we have described is a set of attributes that should apply everywhere regardless of the type of software that you are developing/assembling/deploying.
Beware of INVEST!
INVEST is pneumonic coined by early agilists to provide some kind checklist to user stories. It stands for:
- I” ndependent (of all others)
- “N” egotiable (not a specific contract for features)
- “V” aluable
- “E” stimable (to a good approximation)
- “S” mall (so as to fit within an iteration)
- “T” estable (in principle, even if there isn’t a test for it yet)
We like checklists but we find that there are too many deficiencies with the INVEST list to be universally reliable for assessing requirements quality and advise against its use.
Fails to ensure that stories are User-oriented
If software is not doing something useful for a user, it is not useful. If our stories are not user-oriented, then they are simple work tasks. And this what so many user stories end up becoming, tasks not expressions of user recognisable functionality or capability. In short your expression of done will likely be poor.
Fails to ensure Consistency
If you only follow these guidelines you are likely to end up with requirements that muddle user/persona names and have many different terms for object types.
Fails to ensure Sizeable
By referencing Estimable and not sizeable this approach fails to ensure that each user story has (functional) size. Functional size is not only valuable for project management but is a good test of requirements quality. A sizeable requirement is a good quality one.
Fails to ensure Design-Free
Relying only on INVEST will cause your user stories to become muddled with tasks (and “technical user stories”) this distances the work from the user and it’s value to them.
Using ScopeMaster
Within an hour of first using ScopeMaster you will be finding and fixing requirements defects faster than ever. Depending on the quality of the original requirements, you could be finding and fixing as many as 200 defects per day. Can you think of any other activity would be so productive at finding and fixing defects?
Follow these steps:
- Import your users stories (via a CSV file).
- Click “Analyse all” (you may have time to grab a coffee).
- Explore the results of ScopeMaster’s analysis
- Start with the ambiguous ones and reword them to make them clear user-oriented functional user stories
- Use the auto-generated data dictionary and use case model to ensure consistent user naming
- Use the CRUD analysis to ensure consistent object naming
- Examine the quality feedback that ScopeMaster provides to further improve them.
- Use the CRUD analysis to ensure the set of requirements are complete
