- 10.3 Overview of Features
- 10.4 Benefits of Feature Preparation
- 10.5 Feature Preparation Activities
- 10.6 Timing of Feature Preparation
- 10.7 Assessing Readiness
- 10.8 Accounting for Preparation Work: Tasks and Spikes
- 10.9 Specifying Features and Their Acceptance Criteria
- 12.4 MVP Planning
- 17.3 Why Do We Need a Scaled Agile Approach?
- 17.4 Planning: Choosing an Approach That Supports Inter-team Collaboration
- 17.8 Scaling the Agile Organization
- 18.6 Agile Corporate Culture
- 18.7 Overview of Principles and Practices for an Agile Corporate Culture
- 18.8 Three Principles for Applying Agile Practices
This chapter is from the book
This chapter is from the book
This chapter is from the book
10.9 Specifying Features and Their Acceptance Criteria
Meet with business representatives, developers, and testers (sometimes called “the Triad”) to describe the feature in a way that clearly communicates the requirement. Chapter 8, “Seeding the Backlog—Discovering and Grading Features,” section 8.7, provides guidelines for specifying features using the Role-Feature-Reason (Connextra) template. Coach stakeholders and the team to use the template, but don’t force its use where the resulting wording is unnatural and impedes understanding.
Then, specify feature AC. AC play a central role in agile analysis: they serve as requirements and as the basis for user acceptance testing (UAT). For the first release of the feature, specify just enough AC to define an MMF—the minimum functionality required to deliver value that the customer would view as significant.
As an analyst, you support feature AC specification. You support ATDD guidance by ensuring AC are specified before work on the feature begins so that they can serve as specifications by example. The AC tell the developers how much functionality must be delivered for the item to be releasable—providing them with the information they need to estimate the feature for capacity planning. The AC also serve as test scenarios to validate the solution. These scenarios describe how the product must behave when user stories are strung together in a larger workflow or value stream. A common approach is to specify the AC in a feature file in the Gherkin syntax so they can be interpreted by a test automation tool such as Cucumber.
AC and estimates are so intertwined that you should encourage stakeholders to discuss them at the same time with developers and QA professionals so trade-offs can be explored. This is the principle behind the Triad approach, discussed in Chapter 13.
For more on the Triad, see Chapter 13, section 13.6.3.
10.9.1 Specifying Epic Acceptance Criteria
Specify epic AC that communicate, at a high level, the minimum requirements for completion. In Chapter 7, we saw the following epic example. Its AC expresses the epic’s business objective, “legacy system can be retired.”
The following AC examples specify minimum capabilities for an epic.
10.9.2 Specifying Feature Acceptance Criteria
Like epic AC, feature AC do not have to cover all possible scenarios. Instead, begin by specifying an MMF that includes only the minimum level of functionality needed for the feature to be seen as valuable by customers.
Following is an example of feature belonging to the epic we saw earlier: “As a planner I want to introduce dropship capability to increase top-line sales without the inventory ownership expense.” Its AC are specified in brief descriptive text, also known as scenario titles.
Following is an example we saw in Chapter 8.
10.9.3 The Analyst Contribution
As an agile analyst, you support ATDD by facilitating Triad conversations between stakeholders, QA, and developers about AC and by specifying AC, as discussed earlier. However, you should review and adjust your contribution over time based on experience. Options for your involvement in feature AC include the following:4
You own the feature files—or the team as a whole owns them.
You write the AC, scenario titles, and Gherkin given/when/then specifications—or you write AC and scenario titles, and QA professionals write the given/when/then specs.
10.9.4 Analyze AC During Triad Meetings
Analyze AC for epics and features incrementally, through collaborative sessions with business stakeholders (representing the customer), testers, and developers—the Triad.
Before committing a feature to development, facilitate Triad discussions to specify high-level AC in the language of the business. The AC and conversations clarify the requirements to stakeholders, testers, and developers. Continue to meet with the Triad to refine the AC with more specific test scenarios.
See Chapter 13, section 13.6.3, for more on the Triad.
This chapter focuses on feature preparation, but you also need to prepare stories and their AC. Story preparation and AC are discussed in Chapter 13.
10.9.5 Specifying AC in the BDD Gherkin Syntax
The Gherkin syntax is widely used because it can be easily interpreted by stakeholders, testers, and test automation tools. Typically, you begin by writing story AC informally; then, as the story approaches development, you specify test scenarios in Gherkin feature files. Gherkin includes keywords such as given, when, and then to identify standardized aspects of test scenarios.
For example, you create the following feature to introduce dropship capabilities.