An often-cited bugaboo of many projects is scope creep-the unrestrained expansion of requirements as the project proceeds. Yet requirements development is about gaining an ever-growing understanding of requirements. So, isn't scope creep normal? Find out in this week's column as Ellen Gottesdiener explores exactly how to keep scope under control.
It's true that requirements evolve as you explore, analyze, prototype, and build a product, so some growth is expected. The key concept is "unrestrained expansion." As you learn more about requirements, you have to make sure they are in scope-and if they are not, whether they should be.
All teams need to establish scope and reasonably react to changing needs. In working with teams starting up their product development efforts, as well as those in the midst of contentious projects, I have found a set of efficient, simple ways to explore, communicate, and adapt product scope
Your Product Vision
To paraphrase the Cheshire Cat of Alice in Wonderland , "If you don't know where you're going, any road will take you there."
Having a product vision keeps scope in check because it provides all stakeholders with a common understanding of the final product for all stakeholders. It serves as a rallying point or "elevator test" (something that anyone on the project can explain in a minute or so, as if to someone between floors in an elevator). Derive your product vision by collaboration-gather key stakeholders together to co-create the vision. You can use a vision statement or a visual diagram to articulate the vision.
A product vision statement articulates three things: what you need to build, for whom you need to build it, and how it's different from what now exists. (For a fast and effective vision statement format, see my book The Software Requirements Memory Jogger . This template is based on Geoffery's Moore's product differentiation statement from his book Crossing the Chasm .)
You won't know whether new or changing requirements are valid unless you know whether they're aligned with the product vision. In addition, I recommend that teams create a visual diagram, metaphor, or product box (a low-fidelity physical package for the product, as if you were going to buy it at a computer store).
I noticed while working recently with an agile team that their focus was on delivering stories to test the architecture. Priorities were being determined by the team because the business customer (product owner) was disengaged and rarely attended their iteration planning workshops.
It wasn't until we conducted a backlog-development workshop in which an early activity was to build the product vision (in both words and drawings) that the team and customer converged on what requirements were most important to deliver. The customer thereafter attended each iteration-planning workshop as well as the daily standup meeting. The vision statement and visual posters remained in the team room. At the start of each iteration-planning workshop, the team referred to the vision as the way to start the discussion with the customer about the theme for that iteration, which had to align with the product vision.
Useful Scope Models
When the stakeholders have agreed on the vision, it's time to create requirements models (representations of requirements using text and diagrams) to articulate the boundary between what is in and what is out of scope for the product. Sample scope models include a context diagram and an event-response table. These models should be developed collaboratively with the product owner and other business experts.
One infrastructure team I worked with was having difficulty getting started on the project and knowing which people were needed to deliver enhancements to their document-management platform. Once we started to model the needs using a context diagram and event-response table, they began to question, argue (in a good way), and then agree on what interface changes were needed and what skills were required to get the job done.
If your product will support