INVEST Criteria is an important part of user story writing. This criteria to make sure that the stories that we are planning to commit in a sprint, properly structured and good to commit in the sprint to finish. The intention is to start something to finish, not just to keep it in progress because of any dependency, size, or from a testing perspective.
Here the INVEST acronym stands as below –
I – Independent/Immediately ready to work upon
Here before we take the stories in sprint or mark stories as ready to be taken, need to make sure that stories have less or no dependency. We should assess all the dependencies in the system that can impact these stories. These dependencies may be due to size also. We may be including a lot of functionality in one story and these functionalities would be dependent on each other. When any functionality does not work or have some issue, other parts of the story is block and the story not marked done.
Hence try to separate multiple functionalities or pieces into different stories. Make smaller independent stories. So all can flow through seamlessly, even if there is any issue or blocker, just that the story is block, and not have an impact on others. So possibly stories should create independently where no or less dependency on other stories.
N – Negotiable
The Product Owner usually creates the stories. Though anyone in the team can add items to the backlog. The Product Owner takes a call on what priority stories take up in the sprints. The Product Owner brings stories to the team and explains what needs to done. What the purpose of the story or what we are trying to achieve, and what the acceptance criteria’s to mark this story done. Now team may have questions/concerns and they would discuss them with the PO.
Here negotiable means these details in the stories are negotiable based on the discussions the team would have with PO. The team may have different perspectives, technical insights/challenges/concerns based on which they would suggest some changes in the scope/acceptance criteria of the story. PO should be open to discussing the questions/concerns and make changes if he/she feels makes sense. Hence keeping the option open to have negotiation with scope/details/acceptance criteria based team’s input.
Photo by Annie Spratt on Unsplash
V – Value
As the heading says it is about value. Any story which team is planning to work on in the next sprint or future sprints should add some value to the customer. The value part may be long-term or short-term. Like team may be working on items which is part of current enhancement/features or may be working on some tech debt items that add some value in the future, but the idea is to add some value.
The team should not take up any work which will not add any value. Now who will decide what adds value and what does not? So the answer is Product Owner. PO is accountable for maximizing value for customers. PO would make sure that the team always works on items that have some value. He/she would make sure the Product Backlog always prioritized and a live document to deliver value in each sprint.
E – Estimable
It is important to know when some stories possibly done. Estimation is a way to get some idea about it. So when we are refining stories, we need to know whether the story is estimable. Do we have all the required information to estimate the story? If we don’t have all the information, we don’t know the size of the story, consequently we don’t know how long it will take us to complete this story and when it will be done. If we don’t have this information, we can’t commit this story to the sprint. So we need to make sure that the story is estimable based on the available information, if not then should wait until we have this information.
S – Small
The format of Scrum is iterative, incremental, and shorter delivery cycles to get early feedback from stakeholders and customers. To make delivery happen in shorter cycles, stories should complete in shorter cycles. For that stories should be small enough to complete inside a sprint. If the story is not small enough to complete in a sprint, teams would not be able to complete it and there would be spillovers to the next sprint. This would fail the whole purpose of delivering in shorter cycles. So if stories are big enough to complete in the sprint, they should slice.
Vertical slicing is one of the possible ways to do slicing. In vertical slicing, all functions included to make it a shippable functionality, i.e. Dev, QA, DB, UX, etc. The thought here is that it should be usable and able to add value to customers. Otherwise, it is no use to the customer if you just deliver developed code but not tested, or UI or DB parts are missing. It would be a half-baked dish. Hence story should be small enough to complete in the sprint’s timeline.
T – Testable
This criterion speaks about whether the story is testable. The team should ask themselves, do we have enough information to test this story ? Do we know what kind of testing required? Do we know the scope of the testing i.e. how much testing would be enough seeing the shorter cycle i.e. sprint timeline, would it be feasible to finish the testing also in the same sprint? If not, then maybe the team should slice the story.
The team should make sure that each functional story tested enough before delivery or marked as done by the end of the sprint. Testing is an important aspect and should not miss The anti-patten seen here is team would develop in one sprint and test in another sprint. That is again not delivering value to the customer, like a half-baked dish.
The Team should review INVEST Criteria in backlog refinement. It is a way to make sure that whatever team is planning to commit, they would have a good chance to finish it. Though there may be some impediments coming their way during the sprint. INVEST Criteria also allows the team to review their dependencies, acceptance criteria for stories, estimation, and testing strategy to make sure they are delivering potentially shippable product increments every sprint.