A team may be asked to build an online journey planner, yet still not know why anyone needs it. A business goal states the result the organization wants, rather than prescribing the software to build. For a commuter service, “reduce average travel time for regular commuters by 10% within a year” gives the team a clearer target than “build an application for planning journeys.” section 3.2.1 section 4.2.5
Make the goal visible to sponsors, users, developers, and testers. When a requested feature proves costly or technically impractical, a team that understands the intended result can propose another way to achieve it. Delivering every requested feature is not success if the underlying goal remains unmet. section 3.2.1 section 4.2.5
To turn a broad ambition into a useful business goal:
- Ask why the project matters before accepting a proposed solution. Stakeholders often describe the feature they have in mind rather than the value they need. section 4.2.8
- State the expected benefit precisely enough to assess it. A good goal is specific, measurable, achievable, relevant, and time-bound; “increase ticket sales by 5%” is clearer than “improve sales.” section 4.2.6
- Connect proposed features to the goal. An Impact Map starts with one business goal; features then give users capabilities that may help achieve it. section 4.3.2 section 5.2.1
From outcome to feature
An airline might aim to increase ticket sales revenue by 5% over the next year. Online membership renewal is a possible feature if easier renewals help prevent lost sales from lapsed memberships. Writing the business benefit alongside the stakeholder and requested capability keeps that reason visible when the feature is discussed or reprioritized. section 4.2.7 section 5.2.1 section 3.2.3
In order to increase ticket sales by 5% over the next year As the Flying High Sales Manager I want to encourage travelers to fly with Flying High rather than with a rival company
The goal-first statement places a measurable sales outcome ahead of the stakeholder and proposed approach; it keeps the requested capability distinct from the result it is meant to produce. section 4.2.6
A goal guides discovery; it does not lock down every requirement. In behavior-driven development, the team identifies goals and candidate features, discusses concrete examples, turns selected examples into executable specifications, and checks the delivered feature. It must also validate whether the feature produces the promised value in the real world: passing acceptance tests shows that specified behavior works, not that the business goal has been achieved. section 3.1 section 2.3.1
