A feature is a tangible piece of software functionality delivered to users or other stakeholders to support a useful capability. It should help achieve a business goal, not merely satisfy a request for a particular solution. In online banking, transferring funds between a client’s accounts and transferring funds overseas are distinct candidate features serving the broader goal of convenient account management. section 2.3.1 section 5.2.1
Start with the goal, ask what users need to be able to do, then propose features that could provide that capability. Discuss candidates with business stakeholders, developers, and testers rather than passing a fixed requirements list between them. A requested solution may change when the team examines its value, cost, or testability; understanding of requirements also changes as users see working software. section 4.2.1 section 2.3.2 section 2.3.3
Online membership renewal
Suppose members must telephone or mail a form to renew, and lapsed memberships may cost sales. “Renew membership online” is a candidate feature: members gain an easier way to renew, while the business aims to reduce lost sales. A short description can name the intended value, stakeholder, and desired behavior: “In order to reduce lost sales from lapsing memberships, as a sales manager, I want members to be able to renew their membership online.” section 5.2.1
A feature is not necessarily a User Story. The feature describes functionality delivered to stakeholders; stories are planning chunks used to work out and deliver it. A feature might require several stories and more than one iteration. When splitting one, ask whether a smaller piece can be used and tested independently and whether stakeholders would value releasing it alone. “Pay renewal fees with Visa” may be too narrow to stand alone if it covers only one part of renewal. The boundary depends on the project, not a universal naming rule. section 5.2.2 section 5.2.4 section 5.2
Figure 5.7 Breaking down features into smaller features or User Stories makes them easier to organize and deliver.
The decomposition diagram shows how a larger feature can become smaller features or iteration-sized User Stories without treating every planning chunk as an independently valuable feature. section 5.2.2
Refine upcoming features with examples and acceptance criteria, then use concrete scenarios to expose assumptions about how each should behave. Where practical, automate those criteria as executable specifications: they can check the delivered behavior and remain as living documentation. The feature description and its examples continue to explain what the software does after implementation stories have served their planning purpose. section 5.1 section 3.8 section 5.2.4
