- Communicating the Agile Vision
- Vision Content: A Set of Features
- Undelivered Features Fill the Release Backlog
- Critical Non-Functional Requirements
- Summary
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Vision Content: A Set of Features
No matter the form, the main content of the vision document is a prioritized set of features. In my book Managing Software Requirements: A Use Case Approach, I describe features as "services provided by the system that fulfill a user need." Features are "big picture" system behaviors that can be described in a sentence or two, and they're written so that customers can actually understand, debate, and prioritize them.
Of course, the Agile world didn't invent the word feature or the usage of the word in that context. Rather, we simply fell back on industry-standard norms to describe products in terms of (for example) a features and benefits matrix that has been used traditionally by product marketing to describe the capabilities and benefits provided by our new system. By applying this familiar construct in Agile, we also bridge the language gap from the Agile project team/product owner to the system/program/product manager level, giving those who operate outside our Agile teams a traditional label (feature) to use to do their traditional work (in other words, to describe the thing they'd like us to build).
In the same text, I posit that, by managing the level of abstraction, a system of arbitrary complexity for everything from the space shuttle to the spellchecker on this so-so editor can be described in a list of 25 or so features. That idea still works for Agile teams describing a vision today, and features can still be used as the primary placeholder for user value.