An outcome is something one type of user can do once a project ships. Outcomes say what a project delivers. They are also how you check, later, that the work is done.
Where to find them
Open a project. On its Overview, the Scope tab lists the project's Outcomes.
How an outcome is written
Each outcome is one line with three parts:
A check box. You tick it when you have seen the outcome working.
A short name, in bold. For example: Move a visit myself.
One sentence. It names the user, and says what they can now do. For example: "A customer with a booked visit picks a new open time in the app and has it confirmed without calling support."
How many outcomes
Most projects have 1 to 3 outcomes. If a project has more than 4, split it into two projects, or move some lines to the Requirements.
Check each outcome
Grove checks every outcome before it writes it. You can use the same four checks:
Check | Ask yourself | If it fails |
A user | Does it name a type of user from your Opportunity and Solution or your Target Personas? | If the product is the subject, it's a rule. Move it to the Requirements. |
Why | Is "why does the user do this?" answered by another outcome on the list? | It's only a step. Fold it into that outcome. |
How | Is "how is it done?" answered by the rest of the list? | It's a goal for the whole initiative, such as a number to reach. Leave it in the Opportunity and Solution. |
Coffee break | After this outcome alone, has the user finished something they set out to do? | It's a rule. Move it to the Requirements. |
Here are examples from a booking app:
Line | Problem | What to do |
Move a visit myself. A customer picks a new open time in the app and has it confirmed without calling support. | None. This is a good outcome. | Keep it. |
The calendar shows only open times. | The product is the subject. | Move it to the Requirements. |
Pick a new time. and Confirm the new time. as two outcomes | Each one is only a step. | Fold them into Move a visit myself. |
Reschedule calls drop by half. | It's a goal for the whole initiative. | Keep it in the Opportunity and Solution. |
Keep these out of an outcome
How it works.
Edge cases.
Links to other projects.
"So that..." reasons.
These belong in the Requirements. Keep outcomes as user goals and the rules in the Requirements. Then you can move an outcome to another project without rewriting it.
The short name matters
The bold short name is how Grove finds the outcome. Builders quote it in their pull requests to say which outcomes their work delivers. Delivery tags and threads use it too.
You can reword the sentence at any time. Change the short name only when the goal itself changes.
Write and change outcomes
With Grove. Grove writes outcomes when you break an initiative into projects. To change them later, ask Grove in the chat, such as "Add an outcome to P-003 for pros who want to block off time." Grove shows you the outcome exactly as it will be written, and waits for your yes. It also asks before it adds, drops, renames, or moves an outcome.
Yourself. On the project's Scope tab, click Edit scope. Change the text, then click Done editing. Your changes save as you type.
Tick an outcome
The check box is yours. Tick it when you have seen the outcome working. Grove never ticks or unticks an outcome.
The tag next to each outcome, such as Nothing linked or Ready for review, shows how the work is going. See Review shipped work and mark outcomes done.
Related articles
Settle the requirements
Review shipped work and mark outcomes done