When teams deliver features end to end, they can get engaged with business users much better in designing the scope and determining what actually needs to be built, simply because they can discuss full features with the users.
Even without high-level control of project scope, teams can still influence what gets built by:
- Actively challenging requirements.
- Understanding the real business goals.
- Understanding who needs what functionality and why.
The result will not be as good as when the right scope is derived from business goals from the start. But this approach prevents unnecessary rework later in the process and ensures that the business users get what they really need.
There is a lot of innovation in this field at the moment. To learn more about cutting edge techniques for deriving scope from goals and mapping out the relationship between them, look for resources on feature injection, effect maps, and user story mapping.
- When you get requirements as tasks, push back and understand the real problem, then collaboratively design the solution.
- Think about the business goal of a milestone and the stakeholders who can contribute or be affected by that milestone to derive the appropriate scope.
- If you can’t avoid getting tasks, ask for high-level examples of how they would be useful to understand who needs them and why, and then design the solution.
- Specify using examples and define acceptance criteria on both the higher (feature) and lower (story) levels.
- Start with the outputs of a system to get the business users more engaged.
- Reorganize component teams into teams that can deliver complete features.
- Investigate emerging techniques including Feature Injection, User Story Mapping, and Effect Maps to derive scope from goals effectively.
For more information about Gojko Adzic's Specification by Example, including source code, sample chapters, online author forum, and other resources, visit the publisher's page at http://www.manning.com/adzic/.