Product Owner Team INVEST Criteria

In most organizations, the knowledge necessary to break down user stories in this manner is not contained within a single individual.  With more complex products, there is usually a team of people required. Some of which may, or may not be, assigned directly to the team.

At scale, quite often we are dealing with business and architecturally significant dependencies, which must be managed across teams.

In these more advanced scenarios, we have a Product Owner Team that sits above the Scrum teams and builds the backlog with greater awareness of the whole system.  Ask ‘who amongst the field of candidates is required to make the user stories independent, negotiable, valuable, estimateable, small, and testable?’  These attributes are called the INVEST principles (created by Bill Wake, popularized by Mike Cohn):

INVEST Criteria

Independent

User stories are the lowest level of functional decomposition.  They are expressed in the canonical form of ‘as a <user>, I want some <product feature>, so that I get some <business value>.  They are lightweight expressions that remind us to have a future conversation with the business.  By writing user stories that are independent, we allow the business to change direction with minimal cost and impact to the emerging product.

Negotiable 

User stories are not detailed specification.  They are not a precise guide for how we are going to build the product, or even what we are going to build.  User stories should be high level enough that we can fine-tune both the business implementation and the technical implementation of the requirement.  This attribute gives us room to inspect and adapt as we learn about the emerging product.

Valuable

User stories are written in the language of the business.  They represent an increment of product that can be demonstrated to a potential customer of the system.  This attribute can be contrasted with a technical task that might have value, but is irrelevant to the business user of the system.  Value has to be in the eye of the business stakeholder.

Estimateable

This attribute implies that the team has enough knowledge about how the user story will be developed (and tested) that they can provide a high-level estimate for how long the user story will take to implement.   As the user story is about to be pulled into the sprint, the user story must be well known enough that the team can provide a detailed estimate at the task and hour level.

Small

You might also express this attribute as ‘sized appropriately’.

Small user stories allow us to test the software and get feedback from our customers early.  Early delivery allows us to rapidly reduce the risk that we are building the wrong product or that we are accumulating unnecessary technical debt.

Testable

Testability of a user story is defined up-front before we pull the user story into the sprint.  This means that we know the conditions of acceptance before we start working on the requirement.  We know what it will take to satisfy our customer’s need and how we will verify that those needs have been met.

Product Owner Team

The Product Owner Team must be relatively small and empowered, but have all the people necessary to serve the role of Product Owner for the team.  This group must be able to decompose the product backlog according to the INVEST principles.   This is a big job and usually implies that the Product Owner team has representation from at least: Product Management, Project Management, Architecture, Development, Quality, and Business Analysis.

Success Criteria

The measure of success for the Product Owner team is simple.  Does the Product Owner Team have an understanding of the entire scope of the release?  Do they have enough sufficiently groomed backlog to keep the team busy for at least two sprints?  If both of these conditions are met, the Product Owner team is doing its job.   As we build persistent cross-functional teams that stay together over time, and these teams establish a stable and predictable throughput… the marriage of the prioritized product backlog and the team’s velocity… will allow for fast, highly accurate release planning.

Next post, I’ll explore a bit one of the Product Owner teams I’m working with now, what roles we included, and why we included them.