INVEST Guidelines Valuable CriteriaPosted by BrainConcert
In this third article, it is analyzed the meaning of V from INVEST mnemonic: Valuable. A good user story must define something that is of value to the end user. This could include a feature, performance requirement, or something the user has asked for and can be demonstrated in the sprint review meeting. Technical Product Backlog Items are always more interesting for the team to implement, however they do not always bring value to the customer (or at least value that he can perceive when using the system), and this comes in contradiction with one of the Agile principles which is stating satisfy the customer
through early and continuous delivery of valuable software (see here the list all Agile Principles).
This doesnt mean that you should not have technical Product Backlog Items. One example is a SPIKE. A SPIKE is where the team investigates, researches, and prototype so they understand a fuzzy area well enough to be able to estimate it. But SPIKES need to be time-boxed, they have to have clear goals, and an outcome that's expected. This ensures the SPIKE stays focused using only the time needed to satisfy the goals and the outcome. Letting a SPIKE turn into an opportunity for the team to do fun research and prototyping not related to the issue in the SPIKE, does not deliver value to the end user.
Besides standing for valuable, the V letter can also refer to vertical because when splitting user stories, they should be split vertically instead of horizontally. A horizontal user story will include a complete layer of functionality - network, database architecture, persistent data, some logic, or the user interface, depending on the product architecture. So, for example if the user story says: create the product database, the team will create the database and that's it, we have a database at the end. But database solely, although you cannot have a functional product without it (usually data has to be stored somewhere), is not of value to the customer. The customer does not interact with the database directly, he is using features of the software product. What good is a database without the user interface so it can be viewed and demonstrated? A vertical slice of functionality will have a little of each of those horizontal layers so there will be some database, some logic, some presentation in each user story. Something that can be demonstrated as working code. Coming back to one of the examples used in a previous article, a user needs to be able to register himself in an online application, it is clear that, to implement this user story, the team:
· will need to design and implement a part of the database where the user information will be stored,
· will create the user interface through which the user will provide its information for registration,
· will implement validations of the input data and then the persistence of it into the database,
· will ensure the proper communication between the web server where the application is running and the database server where the database is stored.
This is a small vertical slice and it's a value to user. Now it's important to remember, value is not value in the business sense that you can sell this feature. This user story is much too small a slice of functionality, it's not going to be a business money maker all by itself. And normally, several of these user stories are needed to completely flush out a full feature. However, each user story needs to provide a slice of the feature that is of value to the user. The "V" in the INVEST guidelines stands for Valuable and what is considered valuable is always in the eyes of the end user.