Overview
Goal Setting and Planning is the second CSPO learning objective category and has six objectives. It starts with the relationship between a product vision, the long-range picture of why the product exists, and the Product Goal, the next measurable target the Scrum Team commits to. You then practise writing a Product Goal, crafting a Sprint Goal together with the team, describing the parts of a product plan or forecast you would share with stakeholders, planning a release, and comparing approaches for slicing work into small, usable increments.
Several of these objectives use the verb practise, which signals hands-on exercises during the course rather than memorisation. Scrum Alliance does not score this or any other category, because CSPO certification comes from completing the course and has no test attached.
How it's tested
With no CSPO exam, practice items for this category check whether you can separate the planning layers and apply them. Typical prompts give a vision statement, a goal or a release request and ask which response reflects goal-driven, empirical planning as taught in the course and described in the Scrum Guide.
-
Name the layer
A statement is shown, and you decide whether it is a vision, a Product Goal, a Sprint Goal or a backlog item.
-
Forecast honestly
A stakeholder wants a fixed date and scope, and you choose a forecast approach that shows ranges and assumptions.
-
Slice for value
A large feature is described, and you pick the split that produces a small but usable increment.
A sponsor asks the Product Owner to promise all twelve features of a new portal by March. Velocity history suggests eight to ten will be done by then. A goal-driven Product Owner shares a range forecast based on that data, orders features by value so the most important arrive first, and agrees a Product Goal that describes the outcome the portal must achieve rather than a full feature list.
Learning objectives 6
Official learning objectives from the Scrum Alliance outline, in outline order.
2.1 Explain the relationship between a product vision and a product goalLong-range purpose versus next target.
- What it means
- The product vision describes the lasting purpose of the product and the change it should create for customers. The Product Goal is a concrete, nearer-term objective that moves the product toward that vision and is listed in the Product Backlog.
- What to understand
- A vision rarely changes and inspires direction; a Product Goal is achieved or abandoned before the next one begins. The Scrum Team works on one Product Goal at a time. Product Goals act as stepping stones, so each one should clearly serve the vision.
- How it shows up
- Practice prompts show two statements and ask which one is the vision and which is a suitable Product Goal.
- Common confusion
- Using the vision and the Product Goal as interchangeable terms.
2.2 Practice the creation of a product goalWriting a usable Product Goal.
- What it means
- Creating a Product Goal means stating a specific outcome the product should reach, ideally with a way to tell whether it has been achieved. It becomes the commitment attached to the Product Backlog.
- What to understand
- Strong Product Goals describe a change in customer or business results, such as reducing onboarding time, rather than a list of features. They are ambitious yet reachable within a reasonable horizon and give the team a basis for saying no to unrelated work.
- How it shows up
- A draft goal is shown, and you judge whether it is specific, outcome-based and testable.
- Common confusion
- Writing the Product Goal as a long list of features to deliver.
2.3 Practice creating a sprint goal with a scrum teamA shared reason for the Sprint.
- What it means
- The Sprint Goal is crafted by the whole Scrum Team during Sprint Planning. The Product Owner proposes how the Sprint could increase value, and the team agrees a single objective that the selected backlog items serve.
- What to understand
- A Sprint Goal gives flexibility: if work turns out harder than expected, the Developers can renegotiate scope with the Product Owner while still meeting the goal. It is the commitment for the Sprint Backlog and should be fixed once the Sprint starts.
- How it shows up
- Scenarios ask who creates the Sprint Goal or what happens when scope changes during a Sprint.
- Common confusion
- Believing the Product Owner sets the Sprint Goal alone before Sprint Planning.
2.4 List the components of a product plan or forecast with stakeholdersWhat a shared forecast contains.
- What it means
- A product plan or forecast tells stakeholders what is likely to happen and when. Typical components are the goals or outcomes targeted, the ordered themes or features, time horizons, assumptions, risks, dependencies and a confidence range.
- What to understand
- Forecasts are based on empirical data such as past throughput and should be updated as the team learns. Showing assumptions and ranges keeps stakeholders from reading a forecast as a guarantee. A roadmap organized around outcomes is easier to adapt than one fixed to dates and features.
- How it shows up
- You may be asked which element a good forecast must include or how to present uncertainty.
- Common confusion
- Presenting a single fixed date as if it were certain.
2.5 Describe how to plan a product releaseDeciding what goes out and when.
- What it means
- Release planning decides how and when increments reach customers. In Scrum an Increment may be released at any time, even several times within a Sprint, so release planning focuses on value, readiness and timing rather than waiting for the end of a project.
- What to understand
- A release plan combines an ordered backlog, a target outcome, measured team capacity and any fixed constraints such as a date or regulatory event. The Product Owner usually trades scope against date, protecting quality. Planning is revisited each Sprint as real progress becomes visible.
- How it shows up
- Scenarios present a fixed release date and ask which variable the Product Owner should adjust.
- Common confusion
- Thinking releases may only happen at the Sprint Review or at the end of the Sprint.
2.6 Explain at least two approaches to identify small, valuable, and usable incrementsSlicing for early value.
- What it means
- This objective covers ways to cut work into the thinnest pieces that still give users something useful. Approaches include a minimum viable product, story mapping to find a walking skeleton, and splitting by workflow step, user role, business rule or data variation.
- What to understand
- Small increments get feedback sooner and reduce wasted effort. The slice must be usable end to end, so splitting by technical layer such as database then interface usually fails the test. Story mapping helps choose a first release that covers the whole journey thinly.
- How it shows up
- A big feature is described, and you pick the split that delivers a usable result soonest.
- Common confusion
- Splitting work by technical component and calling each layer an increment.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Product vision
Long-term purpose of the product.
- Remember
- Inspires direction and rarely changes.
- Tested as
- Contrasted with the Product Goal.
- Trap
- Treating it as a measurable target.
-
Product Goal
Next objective for the Scrum Team.
- Remember
- One at a time; part of the Product Backlog.
- Tested as
- Core objective 2.2.
- Trap
- Writing it as a feature list.
-
Sprint Goal
Single objective for the Sprint.
- Remember
- Crafted by the whole Scrum Team.
- Tested as
- Core objective 2.3.
- Trap
- Product Owner writing it alone.
-
Forecast
Expected progress based on data.
- Remember
- Show ranges and assumptions.
- Tested as
- Objective 2.4.
- Trap
- Presenting it as a promise.
-
Release planning
Deciding what reaches customers and when.
- Remember
- Release any time an Increment is valuable.
- Tested as
- Objective 2.5.
- Trap
- Waiting for the Sprint end to release.
-
Story mapping
Arranging work along the user journey.
- Remember
- Reveals a thin end-to-end first release.
- Tested as
- Slicing technique for 2.6.
- Trap
- Building one full step before the others.
-
Minimum viable product
Smallest product that tests a key hypothesis.
- Remember
- Built to learn, not to be complete.
- Tested as
- Slicing and validation link.
- Trap
- Calling a low-quality build an MVP.
-
Vertical slice
Thin piece that works end to end.
- Remember
- Usable by a real user.
- Tested as
- Contrasted with layer splits.
- Trap
- Splitting by database, API and UI.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Vision vs. Product Goal vs. Sprint Goal
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Product vision | Why the product exists | Long horizon, rarely changes | Expecting it to be measurable |
| Product Goal | Next target outcome | Achieved or abandoned before the next | Writing several at once |
| Sprint Goal | Objective for one Sprint | Crafted by the whole team | Treating it as the list of items |
Slicing approaches
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Vertical slice | End-to-end thin functionality | Usable and testable by users | Making it too thick |
| Horizontal layer | One technical layer at a time | Not usable on its own | Calling it an increment |
| Story map slice | Thin pass across the journey | Finds a first release | Building one step fully first |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Feature list goal
- What candidates pick
- Write the Product Goal as the set of features to build.
- Why it looks right
- Features are easy to list and track.
- Why it's wrong
- A Product Goal states an outcome to reach; features are options for getting there and belong in the backlog.
Clue to watch for The draft goal is a bulleted list of features.
-
Product Owner owns the Sprint Goal
- What candidates pick
- Have the Product Owner hand the Sprint Goal to the Developers.
- Why it looks right
- The Product Owner is accountable for value.
- Why it's wrong
- The whole Scrum Team crafts the Sprint Goal at Sprint Planning; the Product Owner proposes how value could increase.
Clue to watch for The question asks who creates the Sprint Goal.
-
Fixed-date promise
- What candidates pick
- Commit to all scope by a single date.
- Why it looks right
- Stakeholders ask for certainty.
- Why it's wrong
- Empirical forecasting uses ranges based on real data, and scope is the usual lever when a date is fixed.
Clue to watch for A sponsor demands every feature by a deadline.
-
Release at project end
- What candidates pick
- Hold all increments until everything is finished.
- Why it looks right
- One big launch feels tidy.
- Why it's wrong
- Scrum allows release whenever an Increment is valuable, which brings feedback and value earlier.
Clue to watch for Usable increments are waiting unreleased.
-
Layer slicing
- What candidates pick
- Build the database first, then the API, then the screens.
- Why it looks right
- It mirrors the technical design.
- Why it's wrong
- Each layer alone gives users nothing usable; vertical slices deliver value and feedback sooner.
Clue to watch for The proposed split follows architecture layers.
Answer framework
Use these steps for any planning or goal-setting scenario in the CSPO course or a practice check.
- Decide which planning layer the situation concerns: product vision, Product Goal, Sprint Goal, release plan or individual backlog item.
- Check that any goal describes an outcome and can be tested, rather than listing features or tasks to complete.
- Confirm who creates it: the Product Owner owns the Product Goal, while the whole Scrum Team crafts the Sprint Goal at Sprint Planning.
- For dates and scope, prefer forecasts built on measured throughput, shown as ranges, with assumptions made visible to stakeholders.
- When work is large, choose the thinnest vertical slice that a user can actually use, and plan to release it as soon as it adds value.
Practice question
Want more like this? The CSPO practice test has questions for every domain.
Checklist
0 of 10
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Start by writing your own product's vision in one sentence, then draft a Product Goal that would move it forward in the next few months. Ask whether someone could tell, at the end, if the goal was met. Next, take a recent Sprint and rewrite its goal so it explains why the Sprint mattered, not which tickets were included. This turns the abstract planning layers into something concrete you can bring to class and discuss with other participants.
In the course, expect exercises on goal writing, story mapping and slicing. Bring a real feature you find hard to split and try several splitting patterns on it. For forecasting, look at a burn-up chart from your team, or sketch one, and practise explaining a range rather than a date. About five to seven hours of reading and practice is enough here. Use the site's knowledge checks only to confirm understanding, since no score affects your certification.
FAQ
How much of the CSPO does Goal Setting and Planning cover?
There is no exam and no published weight. Goal Setting and Planning contains 6 of the 28 CSPO learning objectives, and several of them are hands-on practice exercises during the course.
What is the difference between a product vision and a Product Goal?
The vision is the long-term reason the product exists. The Product Goal is a nearer, testable objective that moves the product toward that vision, and the team pursues one at a time.
Who creates the Sprint Goal?
The whole Scrum Team crafts it during Sprint Planning. The Product Owner brings a proposal for how the Sprint can increase value, and the Developers help shape what is realistic.
Can a team release before the end of the Sprint?
Yes. An Increment can be released whenever it is valuable and meets the definition of Done. The Sprint Review is for inspection, not a release gate.
What should a forecast for stakeholders include?
Target outcomes, ordered themes or features, time horizons, assumptions, risks, dependencies and a confidence range based on real team data.
Do I need to memorise splitting patterns for CSPO?
No test checks memory. The objective asks you to explain at least two approaches, so being able to apply story mapping or vertical slicing to a real feature matters more than recalling lists.
Other Agile & Scrum certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 2 knowledge
You have worked through vision, Product Goals, Sprint Goals, forecasts and release planning. Try a short knowledge check to see whether you can tell these planning layers apart in practice.