Search for a command to run...
The acronym stands for Independent, Negotiable, Valuable, Estimable, Small, and Testable.
I'm the architect of the 3t platform. I've been building scalable platforms for over 25 years and I'm here at 3t digital making event driven microservices in AWS so that clients like yourself can have a hassle free, fast and reliable experience when you use our platform for competency and compliance.
Enhance Visibility of Training and Competence in 3tx Tracking training and competence completion across your organisation is now easier with 3tx’s latest feature. This update introduces group-level metrics, helping you monitor progress efficiently an...
A Highly Requested Feature Now in 3tx
Managing workforce accounts just got easier for organisations using 3tx. Our latest feature allows you to effortlessly differentiate between active workers and leavers, ensuring that your team can stay organised and up-to-date. Now, you can clearly m...
In any organisation, training is the cornerstone of skill development, enabling workers to stay ahead of industry demands. However, what happens when a worker needs training that’s not on their requirement list? In the past, this process could be ted...
Training and competence should be straightforward, but it often gets complicated when workers have to complete requirements that don’t actually apply to their roles. This can lead to confusion, wasted time and inaccurate progress tracking. To fix thi...
2003: the INVEST checklist for quickly evaluating user stories originates in an article by Bill Wake, which also repurposed the acronym SMART (Specific, Measurable, Achievable, Relevant, Time-boxed) for tasks resulting from the technical decomposition of user stories.
2004: the INVEST acronym is among the techniques recommended in Mike Cohn’s “User Stories applied“, which discusses the concept at length in Chapter 2.
In the context of software development, INVEST is an acronym that is used to describe a set of criteria that can be used to evaluate user stories. The acronym stands for Independent, Negotiable, Valuable, Estimable, Small, and Testable. These criteria are intended to help ensure that user stories are well-formed and can be easily understood and implemented by the development team.
A user story should be independent of other user stories so that it can be prioritized and implemented separately if necessary
To make a user story independent, it should be written in such a way that it can be understood and implemented on its own, without requiring any other user stories to be completed first. Here are a few tips for making user stories independent:
Avoid dependencies on other user stories: If a user story depends on another user story being completed first, it may not be possible to prioritize and implement it separately.
Include all necessary information: Make sure that the user story includes all of the necessary information and context for it to be understood and implemented without relying on other user stories.
Use clear and concise language: Avoid using jargon or referring to other user stories in the language of the user story. This will help ensure that it can be understood by anyone on the development team.
Here is an example of a user story that is written to be independent:
"As a new user, I want to be able to create an account so that I can access the app's features. This will involve providing my email address and creating a password. I should be able to do this from the app's home screen."
In this example, the user story explains the desired functionality in clear and concise language and includes all of the necessary information for the development team to understand and implement it. It does not depend on any other user stories and can be prioritized and implemented separately if necessary.
A user story should be flexible and open to negotiation and refinement, as it may change during the development process
To make a user story negotiable, it should be written in such a way that it is open to discussion and refinement during the development process. This can be achieved in a few different ways:
Avoid using specific implementation details: Instead of specifying how the functionality should be implemented, focus on what the user needs and why they need it. This will leave room for the development team to suggest different approaches.
Use "I want" language: Instead of saying "The system should do X," try using language like "I want to be able to do X" or "I want X to happen." This shifts the focus from the system to the user and makes it clear that the user story is open to negotiation.
Use relative sizing: If you are3 using a framework that encourages story points or sizing, instead of giving an exact estimate for how long it will take to implement a user story, use relative sizing to indicate its relative complexity. This can help to make the user story more negotiable, as the development team can suggest alternative approaches that may take less or more time to implement.
Here is an example of a user story that is written to be negotiable:
"As a frequent traveller, I want to be able to save my favourite hotels and flights so that I can easily book them again in the future. This should be easy to do from the app's home screen."
In this example, the user story explains the desired functionality in general terms, without specifying any specific implementation details. It uses "I want" language to focus on the user's needs, and does not give an exact estimate for how long it will take to implement. This makes the user story open to discussion and refinement during the development process.
A user story should provide value to the user or customer
To make a user story valuable, it should provide value to the user or customer. Here are a few tips for making user stories valuable:
Focus on the user's needs: A user story should be written from the perspective of the user and should focus on their needs and goals. This will help to ensure that the user story is valuable, as it will provide the user with something that they want or need.
Consider the user's motivations: Think about why the user wants or needs the functionality described in the user story. Is it something that will save them time or effort? Will it make their experience with the product or service better in some way? Understanding the user's motivations will help to make the user's story more valuable.
Prioritize the most valuable user stories: Not all user stories are equally valuable, so it is important to prioritize the most valuable ones and implement them first. This can help to ensure that the development team is working on the most impactful functionality first.
Here is an example of a user story that is written to be valuable:
"As a busy parent, I want to be able to create a shopping list on my phone so that I can easily keep track of what I need to buy at the store. This should be easy to do from the app's home screen and should allow me to add and remove items from the list as needed. I should also be able to mark items as completed when I have bought them."
In this example, the user story is written from the perspective of the user and focuses on their needs and goals. It addresses a common problem that busy parents face (forgetting what they need to buy at the store) and provides a solution that will save them time and effort. This makes the user story valuable.
A user story should be able to be estimated in terms of the amount of effort it will require to implement
To make a user story estimable, it should be written in such a way that it can be reasonably estimated in terms of the amount of effort it will require to implement. Here are a few tips for making user stories estimable:
Break down large user stories into smaller ones: If a user story is too large or complex to be estimated, try breaking it down into smaller, more manageable pieces. This will make it easier to estimate the time and effort required to implement each piece.
Use relative sizing: Instead of giving an exact estimate for how long it will take to implement a user story, use relative sizing to indicate its relative complexity. This can help to make the user story more estimable, as it allows the development team to compare it to other user stories that they have already completed.
Include all necessary information: Make sure that the user story includes all of the necessary information and context for the development team to understand what is being requested and how it should be implemented.
Avoid including unnecessary details: Too many unnecessary details can make a user story more difficult to estimate, as it will take longer to understand and implement.
Here is an example of a user story that is written to be estimable:
"As a busy student, I want to be able to add assignments and exams to a calendar so that I can stay organized. This should be easy to do from the app's home screen, and should allow me to enter the name, due date, and any notes for each assignment or exam."
In this example, the user story is broken down into smaller, manageable pieces, and includes all of the necessary information for the development team to understand what is being requested. It does not include any unnecessary details and can be reasonably estimated in terms of the amount of effort it will require to implement.
A user story should be small enough to be completed within a single development iteration
To keep a user story small, it should be written in such a way that it can be completed within a single development iteration (sprint). Here are a few tips for keeping user stories small:
Focus on a single goal: A user story should have a single, well-defined goal, rather than trying to accomplish multiple things at once.
Keep it simple: Avoid trying to include too many features or details in a single-user story. Instead, focus on the most important and valuable aspects of the desired functionality.
Break down large user stories: If a user story is too large to be completed within a single iteration, try breaking it down into smaller, more manageable pieces.
Use relative sizing: Instead of giving an exact estimate for how long it will take to implement a user story, use relative sizing to indicate its relative complexity. This can help to keep user stories small, as it allows the development team to prioritize and focus on the most important and valuable pieces of functionality.
Here is an example of a user story that is written to be small:
"As a social media user, I want to be able to upload and share photos from my phone. This should be easy to do from the app's home screen, and should allow me to select photos from my phone's gallery and add a caption before sharing them."
In this example, the user story has a single, well-defined goal, and does not try to include too many features or details. It can be reasonably completed within a single development iteration and can be estimated using relative sizing.
A user story should be testable so that it can be verified that it has been implemented correctly
To make a user story testable, it should be written in such a way that it can be verified that it has been implemented correctly. Here are a few tips for making user stories testable:
Include acceptance criteria: Acceptance criteria are a set of specific conditions that must be met for the user story to be considered complete. Including acceptance criteria in the user, the story will help to make it more testable, as it provides a clear set of guidelines for the development team to follow and for testers to use when verifying that the functionality has been implemented correctly.
Use clear and concise language: Avoid using jargon or ambiguous language in the user story, as this can make it more difficult to understand and test.
Include necessary context and information: Make sure that the user story includes all of the necessary information and context for the development team to understand what is being requested and how it should be implemented. This will help to ensure that the user story can be tested effectively.
Avoid including unnecessary details: Too many unnecessary details can make a user story more difficult to test, as it will take longer to understand and verify that the functionality has been implemented correctly.
Here is an example of a user story that is written to be testable:
"As a customer, I want to be able to search for products on the website so that I can find what I'm looking for.”
Acceptance criteria:
I should be able to search for products by keyword
The search results should include a list of relevant products
The search function should be case-insensitive
The search function should return no results if there are no matching products"
In this example, the user story includes acceptance criteria that provide a clear set of guidelines for the development team to follow and for testers to use when verifying that the functionality has been implemented correctly. The language is clear and concise, and the necessary information and context is included. This makes the user story testable.
