FIRST over INVEST: A Modern Approach to Splitting and Sizing Work

Properly preparing work items for implementation is crucial for successful product delivery. While the INVEST criteria have been a standard for creating user stories and product backlog items (PBIs), a new technique called FIRST is gaining traction as a modern approach to refinement. In this blog post, we will delve into FIRST, highlighting its differences from INVEST, and how it can help you and your organization achieve value more rapidly and enhance your ROI.

Understanding INVEST and Its Limitations

‍

Before diving into FIRST, let's briefly review the INVEST acronym:

-             Independent

-             Negotiable

-             Valuable

-             Estimable

-             Small

-             Testable

The INVEST acronym is a common technique for assessing the quality of a user story. It is often used in refinement. If the story doesn't meet the criteria, teams will often refine it together until they do.  

Where does it come from?

• 2003:     the INVEST checklist for evaluating user stories originates in an     article by Bill Wake, which also repurposed the acronym SMART     (Specific, Measurable, Achievable, Relevant, Time-boxed) for tasks     resulting from the technical decomposition of user stories.
• 2004:     the INVEST acronym is among the techniques recommended in Mike Cohn’s “User Stories Applied ,     “which discusses the concept at length in Chapter 2.

While INVEST has served teams well, it has some limitations:

-             Valuable: Assuming the value of a backlog item upfront is, at best, an educated guess. However, it can lead to a false sense of security about the potential return on investment, which can potentially lead to disaster.

-             Estimable: Estimations can be time-consuming and frequently inaccurate, potentially diverting attention from delivering working software.

Introducing FIRST: A Modern Heuristic For Refining and Splitting Work  

‍

FIRST, developed collaboratively by Becky McNeely, Dan Vacanti, and Prateek Singh, addresses these limitations and aligns with a more accurate, probabilistic perspective on value and delivery: 

-             Feedback Loop

-             Independent

-             Right-sized

-             Small

-             Testable

Let's break down each component of FIRST and see how it improves upon INVEST.

‍

Find the Right Size Using FIRST

‍

Feedback Loop

Get feedback on the work as soon as possible. This helps understand value and ensures you're solving the right problem.

Independent

The work item should not be dependent on any other story or feature.

Right-Sized

The work item must be right-sized for your team. Can it be completed within the team's SLE (service level expectation)? For more information about right-sizing check out this video by Dan and Prateek and read the KanbanPocket Guide!

Small

Make sure the work item is sliced to the smallest piece of deliverable software.

Testable

Can this work item be tested?

Why FIRST Over INVEST

‍

Feed Loop vs. Valuable: Instead of relying on initial guesswork for an item's value, FIRST prioritizes quick feedback. This approach enables teams to validate assumptions, adapt rapidly, and swiftly learn the actual value. As a result, it significantly reduces the overall risk of ROI failure.

Right-sized vs. Estimable: FIRST focuses on efficiently fitting items into the team's workflow rather than spending time on often inaccurate estimations.

Retained Elements: FIRST keeps the crucial aspects ofIndependence, Small size, and Testability from INVEST.

Implicit Negotiability: While dropping"Negotiable" as an explicit criterion, FIRST incorporates this concept in right-sizing and breaking down work items.

‍

Applying FIRST in Your Process

‍

Teams should engage in specific conversations for every backlog item to effectively implement FIRST. Here are the key questions to ask:

-             Am I getting feedback at the earliest possible opportunity?

-             Am I solving the smallest possible problem?

-             Is this being split vertically?

-             Do I think this can fit within our team's cycle time SLE?

-             Could there be potential for some of this to be prioritized differently?

-             Are some pieces more important than other pieces?

-             Is all of this necessary right now?

-             Is there a simpler way to do any piece of this?

Remember: Have these conversations EVERY TIME you refine a backlog item!

‍

Practical Example: Applying FIRST

‍

Let's consider adding a user profile page to an app:

1. Feedback Loop: Can we release a basic version of the profile page for early user feedback?

2. Independent: Is the profile page functionality self-contained?

3. Right-Sized: Can we complete the basic profile page within our team's SLE?

4. Small: What's the smallest valuable piece of the profile page we can deliver?

5. Testable: Have we defined clear acceptance criteria?

Additional considerations:

- Can we prioritize certain aspects of the profile page?

- Are all proposed profile features necessary for the initial release?

- Is there a simpler way to implement any part of the profile page?

Breaking Down Work Items

When an item is too large, consider these strategies: 

1. Acceptance Criteria: Break down based on individual acceptance criteria.

2. Conjunctions and Connectors: Look for "and","or", commas, etc., as indicators for potential breakdown.

3. Generic Terms or Plurals: Replace generic terms with specific ones to create smaller, focused items.

4. Optimize Now vs. Later: Focus on delivering a minimal viable increment and optimize in future iterations.

Below is a cheat sheet you can utilize that works perfectly with the FIRST approach!