Skip to content
Software Architecture Guide

INVEST Applied to Architectural Work

Explanation

Section titled “Explanation”

INVEST is a checklist for good user stories (see INVEST Criteria and User Story). The letters stand for Independent, Negotiable, Valuable, Estimable, Small and Testable. Architects can use it to check backlog items that describe architectural work. Some criteria transfer well. Others raise doubts.

Independent. The checklist asks that stories do not overlap in concept and can be scheduled and implemented in any order. Architectural goals and components are often coupled. So architectural items often depend on each other, and this criterion is the weakest fit.

Negotiable. An architectural item starts as a topic for discussion. The negotiation has to end, so that the item becomes specific enough to act on.

Valuable. The checklist means value to the customer. It advises slicing work vertically through the layers, not by technical layer. An architectural item with no visible business value is therefore hard to defend. Clarify its value with the business. If no value appears, the work should not be done.

Estimable. Estimating is often not the architect’s job. The team or other roles usually plan the work. The architect’s duty is to make the item clear enough to be estimated.

Small. Stories are meant to represent at most a few person-weeks of work. For architecture, small also means specific and measurable enough to judge.

Testable. Non-functional requirements, such as performance, can be tested. For architecture, read testable as measurable. A quality attribute scenario (see Quality Attribute Scenario) defines a response measure, the metric used to judge the system’s response. The SEI Quality Attribute Workshop yields prioritized, refined scenarios. These can serve as measurable backlog items.

Ways architecture enters a backlog. One option is to write constraints and non-functional requirements as user stories. Another is the enabler item, which extends the architectural runway of the solution and is managed like customer-facing items.

Example

Section titled “Example”

A team wants faster search. A vague item reads “Improve the search architecture.” It has no stated value and no way to check it. The team rewrites it: “During peak load, search results appear within 2 seconds for 95% of requests.” The business confirms that slow search loses customers, so the value is clear. The 2-second target makes the item measurable. The team then estimates and schedules it. The item may still depend on another item, such as a new index. That dependency is normal for architectural work.

Trade-offs

Section titled “Trade-offs”

Forcing every architectural item through INVEST can distort it. Coupled goals and components rarely allow full independence, so some dependencies must be accepted and made visible. Insisting on visible business value may also push out work whose value is hard to show, so the architect has to explain that value to the business. Measurable criteria take effort to define, but they make the item specific and checkable.

Checks

Section titled “Checks”
  • Each architectural backlog item states its value to the business.
  • Each architectural backlog item has a measurable criterion, such as a response measure.
  • Dependencies between architectural items are made visible, not assumed away.
  • Each architectural item is small enough to be specific and measurable.
Section titled “Related”

Sources

Section titled “Sources”