INVEST Guidelines – Negotiable CriteriaPosted by BrainConcert
In this second article, it is analyzed the meaning of N from INVEST mnemonic: Negotiable. According to the guidelines, a good user story should capture the essence of the customers’ requirements. It's not an explicit contract with all the information needed to do the analysis, design, code, and test of this feature. This puts the team in the context of having questions, they need to discuss with the product owner, and stakeholders, to negotiate what this user story is really trying to express. Now as the user story is developed through these negotiations, details are added until the team understands exactly what the story is describing enough to estimate a level of effort. One of the most important questions the team should ask is how will I know I have done that? This tells them how to write acceptance criteria to determine when the story is done.
Clear acceptance criteria tell the developer how the feature will be tested and gives QA a solid foundation for writing the test plans. If the product owner cannot describe how to know when the feature is complete, more research is needed. During the product grooming meeting, user stories can be changed, rewritten, split, or even deleted, depending on the state of the project and the business needs. And those business needs change as the project progresses. With the product owner's vision, the team will fill in the details of how these user stories are implemented during the Sprint. And the customer will correct that vision or add to the details when the feature is demonstrated at the sprint review meeting, which could lead to modifying existing user stories in the product backlog or adding new ones. What is crucially important is to capture any and all agreements made during collaboration and negotiations into the related user stories, so everyone is on the same page and agreements are not lost.
By putting concrete and strict elements from the beginning into the user story doesn’t really makes it clearer and easier to develop. Beside the fact that the Product Owner should not focus on details about how the user story should be implemented and only on what needs to be implemented, a very detailed description will present just one perspective on the customer requirement and will block any possibility of discussion and debate to really understand all aspect of it. The team has nothing left to ask, everything's documented. It becomes just the old-school way of writing requirements, with no collaboration opportunities between the team and the end user or the stakeholders.
Now there will always be some non-negotiable items, like for example security policies related to user accounts, or performance requirements like the number of simultaneous users that the system has to handle. This is fine, as long as the details of the feature itself are open-ended inviting a conversation.
The "N" in the INVEST guidelines stands for Negotiable. The capability of writing open-ended user stories that invite negotiations enables a collaboration between the team and the stakeholders, which leads to the creation of product which satisfies the user’s needs, resulting in happy customers.