A project is one piece of an initiative that a builder and their coding agent can build, and that your team can ship on its own. Grove helps you split an initiative into small projects, and puts them in the order to build them.
Before you start, the initiative needs its Opportunity and Solution document. See Shape the problem: Opportunity and Solution.
Start
Do one of these:
Open the initiative's Overview. If the initiative has no projects yet, click Break this into projects.
In the initiative's chat, ask Grove: "Break this into projects."
How Grove splits the work
Grove splits the work into the smallest pieces that are useful to a user and can ship alone. It doesn't split by technical parts, such as "the backend" and "the app." Here is why:
Each project ships, and you judge it on its own. You get feedback early, and you can change direction.
The requirements stay about users. Your designers and product team can review them.
You can cut scope. Under pressure, you can drop a whole project and still ship something complete.
How your builders build is up to them. They can still build by technical part, even when the plan is split by user value.
Grove also checks the size of each project. A project that is too small adds work to manage with little gain. A project that is too big ships nothing useful until the end. Each project gets 1 to 3 outcomes: things a user can do once it ships. See Write a project's outcomes.
Answer Grove's questions
Grove asks a few questions first, such as:
Which user problem is the most important to solve first?
Are there deadlines or other limits?
What does a good first project look like for the user?
What is out of scope for this initiative, and why?
Check the proposal
Grove shows its proposal as a short list:
Each project's name, in bold.
Each project's outcomes, written the way they will go into the plan.
Why a project is in that place in the order, when that isn't clear.
What is out of scope.
Grove then asks you to confirm or change the proposal. Grove creates nothing until you confirm. Check the outcomes too, not only the names.
About the order. Grove often puts the most important user problem first. Sometimes it puts the riskiest or least certain project first, so your team learns early. Sometimes a project goes first because the others depend on it. If you want a different order, tell Grove.
If you want a different split. Tell Grove. If you have a real reason, such as a deadline or a dependency, Grove changes the split. If not, Grove explains once why it recommends its split. Then it does what you decide.
You don't have to plan everything at once. If only the first project is clear, plan that one. Add more later.
What Grove creates
When you confirm, Grove:
Creates each project, with its own ID, such as P-003.
Writes each project's summary and outcomes.
Writes the Out of scope list in the Scope document.
Grove then tells you what it created, and why each project is in its place.
Grove doesn't write the Requirements yet. You settle them with Grove one project at a time. See Settle the requirements.
The Scope document
Open the initiative. In the sidebar, under Plan, click Scope. The document has two parts:
Projects: a card for each project, in build order, with its ID, status, and description. Click Show summary to see a project's outcomes. Click the arrow to open the project.
Out of scope capabilities: what this initiative won't do. It also lists things people might expect, so nobody assumes they're included.
Change the projects later
Ask Grove in the initiative's chat. For example:
"Move the 'see the change on my schedule' outcome to P-001."
"Merge P-002 into P-003."
"Put P-001 first."
"Add 'pro-initiated rescheduling' to out of scope."
"Make Sam the lead on P-003, and target the end of March."
You can also drag the project cards on the Scope document to change the order, and click Add project to add one.
If a project already has requirements, Grove tells you when a change may affect them.
Related articles
Write a project's outcomes
Settle the requirements
Move or archive work