What is agile INVEST?
The INVEST agile acronym is a key to remember a set of criteria that you can use to assess the quality of a user story. It acts like a checklist that has been widely used to assess all the components of a user story. Using the INVEST mnemonic, a good user story should be:
I - Independent - The Product Backlog Item (PBI) should be self-contained/ independent of others.
N - Negotiable - PBIs are not contracts for features and there should be space for discussion.
V - Valuable - The PBI has to deliver value to the stakeholders involved.
E - Estimable - You must be able to estimate the size of a PBI to a good approximation.
S - Small - PBIs should not be too big and should fit within an iteration.
T - Testable - The PBI description must provide enough information to make development of a test possible.
Product owners should be able to create good user stories to fit the needs of the team. The INVEST acronym is useful for remembering the components of a good user story. Let’s understand how each of these components comes into play.
I - Independent
The user stories should be kept as independent of others as possible. ‘Order independence’ should be aimed for. This means that there is no particular order of going about with the user stories and they can be worked on in any given order, independent of when the other user stories are done. This makes it easier to prioritize a given story over the others if required.
When there are multiple dependencies, prioritization becomes tough. You might have to implement a story which isn’t really valuable first. Instead, you’d rather be focusing on the ones which are actually important.
N - Negotiable
Know that a story is not a detailed contract and should be brief. User stories are meant to invite further conversation. There should be room for negotiation. The end goal, of course, should be clearly defined, but, the methods of achieving this end goal should be open for discussion.
The final product should be a result of the collaborative discussions between the various parties. These are the product owner who knows what the customer wants, the developers who work on it and the testers. It should be easy for the various people involved to share their thoughts and changes to the methods should be accordingly made if need be.
V - Valuable
At all points, the story should have a value that can be recognized easily by reading the story. If there is no discernable value to a user story, there is no point of going forward with it. User stories should be prioritized in the backlog based on the value, so this seems like an obvious point.
The team should know why they are building the product. Knowing why they are building it could also encourage your team to come up with other, maybe better ways of going about the story.
E - Estimable
The fourth part of the INVEST SAFe agile acronym, to properly prioritize a user story, should be properly estimated. It may happen that a story has a high value but is also very lengthy and this could make you want to keep it at a lower priority. If a story can’t be estimated with ease, you could try to split it into smaller components for approximation.
Developers need to have this information so that they can properly size the story to plan and commit to the work. To draw a proper estimate, the developer needs to have domain and technical knowledge as well as the size shouldn’t be too big. If the developer lacks the first two factors, they need to make up for it. Talking to the person who wrote the user story can help with domain knowledge. Gaining tech knowledge would need a stint of extreme programming.
S - Small
The exact size, or how small a story needs to be depends on your team and their way of working. Epics, containing multiple stories, can be difficult to work with. Similarly, it shouldn’t be too small that it contains just a single step. You need to design your user story around the capacities of your team.
T - Testable
For a story to be successfully completed, it should be tested.. It should be possible to write acceptance criteria/ ensure that the story is testable. Even though there might not already be acceptance tests in place, all the information needed to write them should be available.
As much as possible, tests should be automated. Incremental development could put a lot of things that were formally working into a stagnant state all of a sudden, and automated testing can help identify this fast.
Origins of the agile INVEST acronym
The INVEST agile acronym originally appeared in an article by Bill Wake, in 2003. It was a checklist meant for evaluating user stories.
A year later, in 2004, the technique was recommended in Mike Cohn’s book, ‘User Stories Applied’. The concept was discussed in detail in the book.
Entrepreneurship
