To quote Ken Schwaber: “The minimum plan necessary to start a Scrum project consists of a vision and a Product Backlog. The vision describes why the project is being undertaken and what the desired end state is.” (Schwaber 2004, p. 68). This is great, it seems so simple, a vision of what you want to build and a list of stuff that is needed to achieve that vision.
Of course, there is more to this simple statement than it initially appears. The “vision” summarizes what the anticipated output of the project will be like. It is similar to what the Project Management Institute (PMI) calls the product which is created by the temporary endeavor of the project. For clarity throughout this discussion, we will call Schwaber’s “vision” a Product Vision. Unlike PMI’s expectation that a “project has a definite beginning and end”, a Scrum project emerges the product and cannot antecedently know when the project can be said to be “done”.
For this article we will be focusing on the mystery of what constitutes a Product Vision. The second part of the start of a Scrum project, a Product Backlog, will be left to a later date when we begin to address agile requirements and scrum requirements management.
What Is the Product Vision?
A Product Vision states the purpose for which a project is performed. It summarizes a broad expectation of what the product will be like and the benefit it will have for customers and/or users of the product. Essentially it describes some future state of the product and the problems it attempts to solve or needs it endeavors to fulfill.
One may wonder if a Product Vision is analogous to a PMI Project Charter. Although there are areas where PMI and Scrum have similarities, this is not one of them. To quote the PMBOK Guide, a Project Charter is a document that “formally authorizes the existence of a project and provides the project manager with the authority to apply organizational resources to project activities.” (Project Management Institute) Whereas, a Product Vision is almost certain to be documented, is unlikely to be formal, and carries with it no level of authorization. The only thing that really is analogous between a Project Charter and a Scrum Product Vision is that they are both very early in the project process.
The definition of a formal starting artifact and authorization of a project are further areas where Scrum is “silent”. How these tasks are completed is dependent on the performing organization and may differ from project to project.
How Do I Know I’m Doing it Right?
As we know, Scrum works best where the product of the project is not completely understood prior to commencing the effort. If the product is really well understood, then a waterfall approach might be a better selection of methodologies. Given the level of uncertainty on Scrum projects it is important to tailor the Product Vision so that it does not become an impediment to the flexibility required to develop the product in an Agile manner. Remember that products are said to emerge from a project that uses a Scrum framework
- Encompassing – Widely shared and understood Product Visions are likely to have greater support and acceptance from project stakeholders. The vision should fit the performing organization’s culture, goals, and strategy.
- Engaging – The vision should engender in stakeholders, and especially the project team, a deep investment in the product. The more the team believes in the vision, the more effective the build the project will be.
- Expansive – Tending to include ideas rather than reject them, an expansive vision affords the flexibility that fosters the emergence of the product. It is important to resist the temptation, at this point, to become too detailed in the definition of the Product Vision.
- Essential – It is important to be able to express the Product Vision in an economical and succinct manner. A useful Product Vision is frequently likened to an elevator speech, which can be stated in the time it takes for an elevator ride. Reducing the vision to its absolute minimum allows the team to focus on the essential element of the benefit of the product.
Products created though agile frameworks and methodologies emerge through the performance of the project. These four characteristics provide breadth, acceptance, flexibility, and clarity needed to allow this emerge to occur.
As the Product Vision provides guidance, though these four characteristics, the project has better chance of producing a valuable output, it has a better possibility being able to impart benefit to the performing organization. After all, the potential to earn is the reason why the time and cost associated with creating a product are expended.
To Create a Product Vision, Start at the Beginning
Templates are good at framing the questions that need to be answered or understood to be able to perform a task. Note that templates are only guidelines and shouldn’t be slavishly followed. To emerge anything in scrum one must have the flexibility to embrace change.
A excellent template to help with getting started on creating a Product Vision can be found in Geoffrey Moore’s classic book on high technology marketing: Crossing the Chasm:
For: [target customer]
Who: [statement of needs or problem domain]
The: [product name] is a: [product category]
that: [product benefits for the customer, reason to buy].
Unlike: [competitors’ alternatives],
Our product: [differentiation or value proposition]
For example:
For [a Scrum product owners] who [need to author product visions] the [Crystal Ball of Agility] is a [business value mind map brainstorming tool] that [guides the user through the process of investigating and determining the potential value and associated benefits of identified marketplace needs]. Unlike [The Tome of the Waterfall] our product [will produce valuable business product visions without massive volumes of restrictive and costly requirements documentation].
Remember the Absolute Minimum
At the absolute minimum, one of the two things that are required to start a Scum project is a Product Vision. Remember, Scrum is very focused on finding the minimum necessary to accomplish a stated goal and the idea of a Product Vision is a clear case in point. The importance of creating a Product Vision that meets our stated characteristics cannot be stressed enough. Producing a good Product Vision will provide broad acceptance within the performing organization, guidance to what user stories to include and exclude from the Product Backlog, flexibility to foster the emergence the solutions, and a clear, concise, easy to understand, and easy to communicate statement of the reason for performing the project.
Everything within the project needs to be able to point to the Product Vision as its reason to be done. If a task, user story, sprint, release, or endeavor cannot point to the Product Vision, then it should be eliminated. This approach will help to keep the project focused on delivering the value, with a minimum of effort and cost.
Leave a Reply