Collaborating on deriving scope from goals is undoubtedly the most controversial topic in this book. In the last five years, the surge in popularity of value chains in software development has increased awareness of the idea of collaborating on scope and deriving it from business goals.
On the other hand, most teams I work with still think that project scope isn’t under their control and expect customers or business users to fully define it. In the course of my research for this book, I found a pattern of teams deriving their project scope from goals collaboratively – but this practice is much less common than other key patterns.
I originally thought about leaving this chapter out. I decided to include it for three reasons:
* Defining scope plays an important role in the process of building the right software. If you get the scope wrong, the rest is just painting the corpse.
* In the future, this will be one of most important software development topics, and I want to raise awareness about it.
* Defining scope fits nicely into designing processes from value chains, which are becoming increasingly popular because of lean software development.
Source: “Specification by Example – How successful teams deliver the right software”, Gojko Adzic, Manning,
Software requirements gathering is often considered by the customers as an activity where they are going to list the desired features of the new software application. In this quote, Gojko Adzic remind us it is more important to know where we are going before discussing what to do. The scope of a project should be defined according to the business goals of the organization. This emphasis on defining goals before features is also the focus of his last book “Impact Mapping: Making a big impact with software products and projects “.
