Completing Vision and Scope Milestones

Learn More about Vision and Scope

Vision and Scope milestones are interrelated with each other. Teams should define the near-term and long-term outcomes they want to achieve. This is all based on their current understanding of the problems that are happening for audiences that they prioritize changing. Every time they do discovery, this vision and scope changes, so they are adjusted throughout the lifecycle.

Before you proceed with this page, learn about the project components, include the agile lifecycle:

Make One Vision and Scope For Each Target Audience

Products aren’t just made from ideas. They take a lot of coordination, research, decisions, and negotiations to make happen. Teams must go through cycles to organize work and decide how to focus their efforts. There are specific deliverables that are involved in different types of projects across research, design, product, and development functions. This training shows the typical cross-functional deliverables set that exist, and how it translates to project phases in Tech Fleet.

Use the Product and Service Vision and Scope Template to make a release-level vision and scope for each audience: https://www.figma.com/community/file/1494349319575390329/product-release-vision-scope-and-roadmap-workshop-template

Determining Priorities

How do you know which problems to solve first? In short: you don't, and no one does. It's all just a guess and a judgment call based on what you know. You could get the guess wrong, and Agile is built for quick adjustments when you get it wrong. One needs to embrace this lifestyle in requirements work for Agile teams. You will constantly be guessing which is the correct way to go. "Continuous improvement" all the way. You can use tools like prioritization matrices to rank problems to solve and decide which ones to solve first. The rest is up to what the team decides to put into their release-level vision, and what they learn after they deliver iterations towards the release.

Use the Product and Service Vision and Scope Template to determine priorities for each release: https://www.figma.com/community/file/1494349319575390329/product-release-vision-scope-and-roadmap-workshop-template

Dealing with Assumptions in the Vision and Scope

Teams are making a lot of assumptions. In fact, every decision a team makes is an assumption. They assume they're making the right decision for the business or for the users. The assumptions could be justified with a lot of research, or backed by estimated guesses, but they are assumptions nonetheless.

Nothing will ever be verified to be true or false until your entire audience uses something and you get enough data that's representative of the population and statistically significant.

Agile teams release early and often, and they continuously improve by testing their assumptions and refining their vision. Over time, they deliver more value to users and validate more assumptions. This is cyclical in nature; every time something gets delivered, new assumptions form, and the team should keep validating every new assumption being made.

The vision and scope formation is a guess full of assumptions. Your guesses could be backed by a lot of research, or backed by none of the research. You should still proceed with a vision board for all of the reasons talked about in the previous sections of the course; iterating requires quickly delivering and checking assumptions. Provide your best guess about the parts of the vision and move toward delivery quickly. In the real world, a vision could be changing every week if Agile teams are performing continuous discovery, or continuous research (as they should).

What does this mean for you?

At some point in your product lifecycle, you will create vision boards and scope that are complete assumptions (shall we call them "Proto-vision boards"?) and your next step should be to validate those assumptions continuously (through continuous discovery). Then you must come back to the vision boards and keep adjusting them over time, and repeat the cycle. In order to refrain from Waterfall practices where the entire vision and scope is defined before work begins, teams must deliver early and often. Agile teams do not need to plan out a long-term release before they start the work.

The vision is never final; the vision is full of assumptions; the vision must be validated continuously; the vision must be adjusted continuously.

Use the Product and Service Vision and Scope Template to form and map assumptions for each release: https://www.figma.com/community/file/1494349319575390329/product-release-vision-scope-and-roadmap-workshop-template

Creating the Release-level Vision Boards

Teams should understand their long-term the end-result that they are trying to achieve. In order to define this, they must have a good understanding (note: NOT a complete or perfect understanding) of the problems users face and the state of the market they're trying to deliver into.

Use the Product and Service Vision and Scope Template to make a release-level vision boards for each audience: https://www.figma.com/community/file/1494349319575390329/product-release-vision-scope-and-roadmap-workshop-template

Creating the Release-level Scope of Outcomes

Scope is often referred to as the "Definition of Done", and in that, it's easier to understand. What are the lists of solutions (i.e. problems) that we the team must deliver in order to consider something a success? You can look at this through the lens of a single feature being delivered or an entire product release that's getting defined.

Use the Product and Service Vision and Scope Template to make a release-level scope outcomes for each audience: https://www.figma.com/community/file/1494349319575390329/product-release-vision-scope-and-roadmap-workshop-template

Head to the Next Lesson