The INVEST technique not only helps the Product Owner communicate product requirements comprehensively but also serves as a factor that enables the Agile team to develop the ability to decide how to work towards achieving their goals (self-managed).
User stories are an important tool for communication between the Product Owner (the product visionary) and the Development Team (the product development team). User stories help the Product Owner convey business value and customer desires to the Development Team, and assist the Development Team in understanding the requirements and proposing suitable technical solutions.
However, not all user stories are good. A good user story needs to meet several criteria to ensure quality and feasibility. One popular technique for evaluating user stories is the INVEST technique, proposed by Bill Wake in 2003.
INVEST is an acronym for:
– **Independent**: Each user story should be a separate requirement, not dependent on other user stories. This allows the Product Owner to prioritize flexibly and enables the Development Team to work on multiple user stories in parallel.
– **Negotiable**: Each user story should have flexibility, allowing the Product Owner and Development Team to discuss and adjust it as needed. A user story is not a rigid contract but a framework to explore needs.
– **Valuable**: Each user story should deliver value to users or customers. This value can be increasing revenue, reducing costs, improving experience, or any other benefit. The Product Owner needs to clearly identify the value of the user story and communicate it to the Development Team.
– **Estimable**: Each user story should provide enough information for the Development Team to estimate the time, effort, and resources needed to complete it. Estimation helps the Product Owner plan and manage the project effectively.
– **Small**: Each user story should be of a moderate size—not too large or too small. A user story that is too large will be difficult to estimate, implement, and test. A user story that is too small will take too much time to manage and communicate. A good user story can typically be completed within a Sprint (work cycle).
– **Testable**: Each user story needs to have clear acceptance criteria so that the Development Team and Product Owner can verify and assess the results. Acceptance criteria also help ensure the quality and consistency of the user story.
**Example 1: Poor User Story**
User story: As a manager, I want to have a human resource management system to track employee information, payroll, leave, and performance evaluations.
– Reasons it is poor:
– This user story is not independent as it includes multiple different requirements in one story.
– This user story is not negotiable; it is a rigid and detailed requirement.
– This user story does not have clear value for the user; it is merely a vague goal.
– This user story is not estimable; it is too large and complex to be completed within a Sprint.
– This user story is not testable due to the lack of specific acceptance criteria.
**Example 2: Good User Story**
User story: As a manager, I want to be able to view employee personal information to know who they are and contact them when needed.
– Reasons it is good:
– This user story is independent; it requires only one feature.
– This user story is negotiable, allowing the Product Owner and Development Team to discuss details and solutions.
– This user story is valuable for the user, helping them manage human resources more effectively.
– This user story is estimable; it is of a reasonable size and simple enough to complete within a Sprint.
– This user story is testable, with clear acceptance criteria, such as: The manager can view the employee’s name, age, phone number, email, and job position; the manager can send a message or call the employee from the system.
The INVEST technique not only helps the Product Owner write quality user stories but also aids the Development Team in working effectively and managing themselves. The ways a team can leverage the INVEST technique to enhance their self-management include:
– The team uses the criteria of the INVEST technique to evaluate and provide feedback to the Product Owner regarding user stories in the Product Backlog. The team can suggest improvements or changes to make the user stories better.
– The team uses the criteria of the INVEST technique to select and commit to user stories that can be completed within a Sprint. The team can estimate the work required and assign responsibilities to each member.
– The team uses the criteria of the INVEST technique to design and implement user stories. The team can identify suitable technical solutions and ensure product quality.
– The team uses the criteria of the INVEST technique to test and review the results of user stories. The team can measure the degree of completion and value of the user stories, and receive feedback from the Product Owner and customers.
As a result, the team can self-determine how to work towards achieving the Sprint goals without needing to rely on external direction or intervention. This empowers the team, enhancing their creativity, collaboration, and accountability.
In summary, the INVEST technique is a valuable tool for writing quality user stories in Scrum. By applying this technique, the Product Owner and Development Team can communicate effectively, understand product requirements, and create value for customers. At the same time, this technique also helps the Development Team enhance their self-management, meaning they can independently decide how to work towards achieving Sprint goals. This is one of the critical factors for success in Agile methodology.
