How to create effective User Stories by following INVEST principles

Eugene LaiFri, 04/27/2018 - 14:06
Subject

In my experience working with many Scrum teams over the past several years, I see very few similarities between organizations in terms of their culture, team dynamics, policies and procedures, and willingness to change. One constant that I have observed is that low-quality User Stories tend to be a common problem that impedes the performance of Scrum teams, especially new teams that are in the process of learning a brand new way of thinking and organizing work. Most teams that I have coached have heard of the I.N.V.E.S.T. principles, either through formal training or informal workshops. However, most teams do not fully understand how to apply these in a practical way, which makes it extremely challenging to adopt them and improve the quality of the User Stories. I will share some thoughts regarding the meaning behind these practices as well as suggestions on how to apply these in real-world projects.

I = INDEPENDENT

One of the biggest problems that Scrum teams encounter are poorly written User Stories due to interdependencies with other User Stories (either within the same team, or another team). The ideal User Story should be self-contained, meaning that it does not rely on other units of work to be completed in order for this work item to be completed, tested, and validated in anticipation of delivery to the customers within the timebox of a single sprint. This is an important factor that many teams struggle to master over months of practice.

N = NEGOTIABLE

Many teams I worked with in past initiatives expect the Product Owner to understand how to write Stories that fit perfectly into a single sprint. The fact is that most Product Owners need help to craft the User Stories with the proper amount of detail, especially in the Acceptance Criteria which draws a boundary around the scope of that specific Story. This means that the Scrum Team should in most cases work closely with the Product Owner to define the scope (i.e. what will be done, what will not be done) for each Story, typically through a Backlog Refinement process. The process of negotiation comes naturally through this process to enable the team to optimize the quality of the User Stories prior to the team committing to them for a sprint.

V = VALUABLE

User Stories are written from the perspective of the “user” because they are intended to articulate the intent of the user to perform a specific process that derives business value of some sort. The perception of “value” comes from the capabilities that the user gains from the successful delivery of the User Story. Usually, assuming the Product Owner has a thorough understanding of the customer, value can be assessed fairly quickly. However, when the team refines a User Story to ensure that it can be fulfilled within the time constraint of a single sprint, sometimes the benefit/capability from that Story may be diluted in the process of de-scoping the Story. This is an important aspect to keep an eye on while refining the Product Backlog.

E = ESTIMABLE

A User Story needs to not only have sufficient level of benefit to the user, but must contain enough detail so that the team can perform a relative estimate against other work items in the backlog. This is critical to help the team understand how much work they can commit to within a single sprint. This means that the Acceptance Criteria must be written with sufficient detail so that the team understands the expectations of success.

S = SMALL

Scrum teams generally operate much more efficiently when the work units are relatively smaller in size. This is because larger units of work are inherently more risky due to the increased scope and potential for issues. Hence, most Scrum teams should strive to create User Stories that require less than the full sprint to complete. By sizing the Stories small, the team can adapt to unknowns and unplanned work more effectively, and still meet the sprint goals.

T = TESTABLE

User Stories must be fulfilled by meeting the Definition of Done (DOD) as well as the condition of acceptance (a.k.a. Acceptance Criteria). Most teams that build and deliver technology will typically include testing and validation of the work as part of the DOD. When creating User Stories, it’s usually helpful to engage Test Engineers and allow them to provide input on the effort to successfully validate a capability that is developed by the Software Engineers. There are some situations where the time and effort to verify a new capability far outweighs the effort to build it. As a result, test approach should be clarified as early as possible, ideally when the User Story is written.

It is my hope that the information I have shared helps to clarify some of the confusion around the INVEST model. While most of these seem to be common-sense, in my experience, even the most capable Scrum teams develop the skill to write high-quality User Stories over many months of practice. There’s no need to wait…start writing some User Stories today!