Modern delivery teams using modern product development methods enable making better decisions sooner by treating requirements as tests, which means creating feature specifications. Let’s talk about this.

The goal of this kind of approach is:

• Reduce sources of truth.
• Reduce communication churn and hand-offs between project artifacts.
• Capture communication as examples that demonstrate a shared understanding of quality.
• Encode collaboration as tests that show business intent.

A feature specification becomes the source of truth for determining when the feature is done as well as the means of proving that. This is what spec workshops produce.

• The feature specification is a combination of requirements and tests.
• This is a single source of truth that can be utilized by all members of the team, not just those in the workshop.
• The workshop team will work on high-level test scenarios for each requirement of the feature.
• Feedback is incorporated until it’s agreed that the test scenarios cover the expected behavior of the feature.

This is a good start on feature coverage. (Which is one of the “things that matter.”)

• Not all test scenarios are expected to be done at this point.
• The goal is to provide enough representative examples of the feature providing value.
• You have “enough” examples when:
• everyone feels confidence that the feature is understood.
• there is a shared consensus of what “done” looks like for the feature.

This is a good start on how feature readiness. (Another of the “things that matter.”)

Once you have that common understanding of the requirements and the test scenarios, this is a good opportunity for the developer and tester to provide estimates.

• The developer will be estimating based on the work to develop the feature.
• The tester will be estimating how many more test scenarios are likely to be added and how much automation can be utilized.

Note that “tester” can mean anyone acting in the capacity of testing. This doesn’t mean you have to worry about who was what title. Rather, it means having people with test competence. (“Test competence” is a wider subject that I hope to talk about in a different post.) Anyone can suggest more test scenarios to be added to the feature spec.

Since everyone, including those not in the workshop, should be operating off of that common feature specification, everyone can be aware of the changes as well as the need to re-estimate if the changes end up being large.

Here “estimate” and “re-estimate” do not have to be formal; it can simply mean having a conversation so everyone understands the likely level of effort.

There’s a very important point here: all of this is why feature specifications need to be a source of truth consumable at a glance; not a series of, say, JIRA tickets or Confluence pages that provide only a partial picture of feature coverage and feature readiness. Here “consumable at a glance” doesn’t just mean for the sprint in which they are created for new feature work. These specifications persist as long as the feature exists and is delivering value. That’s why it’s important the feature specifications are understood to be requirements encoded as tests.

I can’t stress enough how the above procedure, when carried out in a sustainable way on a delivery team, massively impacts the delivery of quality. If there was the equivalent of a high-level recipe for delivering quality, I would say the above is, at the very least, a good start on that.

When I work in a product development or product management context, the above material — including the information in previous posts in this series — is essentially how I get delivery teams working together. All of it combined is the intersection of product development with testing. It led us from injecting elements into product documents all the way to testable requirements. All of it was ultimately focused on the notion of acceptance which, in turn, is focused on the value of experience that is provided to users.

That value of experience is, ultimately, how we have to measure quality. Quality is a perception of value. Further, it is a shifting perception of value over time. Recognizing that reality and working in its context is crucial for product development practice. Testing is what enables that practice to be effective and efficient.