Sprint Zero
What should the cadence or structure of events be like for the initial lets say 2 week sprint of a scrum project often referred to as Sprint Zero. What is key to getting accomplished during sprint zero to make the rest of the scrum project successful? Feel free to build on this.
SPRINT ZERO OBJECTIVES:
- Product vision defined and approved
- Kickoff Meeting Completed
- Product roadmap established and initial backlog prioritized
SPRINT ZERO KEY EVENTS:
- Project Kickoff Meeting
- Initial Story Writing Workshop
What product increment is delivered and how would empirical process control be established?
In which Agile methodology is the sprint zero recognized? (It's not in the Scrum Guide ;)
Sprint zero is an anti pattern and shows often weak product ownership, project or portfolio management. Like you wrote, in your case the vision is not defined and approved. I am not sure if the PO is allowed or should start to work with the team without legitimation.
Start your first sprint, when you are sure you can deliver at least one piece of functionality in that sprint.
And check the scrum guide for a sprint zero, if you plan to take the PSM1.
I agree with @Nils Hyoma - there is no such Sprint Zero mentioned in Scrum guide. why would you require Sprint zero as initial step to kick off?
I'm going to take a slightly different stance than the others. You can't look to Scrum for information on this - you'll have to look elsewhere.
Scrum simply does not address the parts of a project or effort that you describe. Scrum is focused on the creation or construction and delivery of products and services, particularly in an uncertain or changing environment. It doesn't address what I'm used to calling the inception or initiation activities - determining and obtaining funding, forming one or more teams, identifying and exploring an initial vision and scope (in Scrum terms, how you end up with a Product Backlog going into the first Sprint), architectural concerns (tools, technologies, existing assets - things that are very hard to change later on), release planning (and, for Scrum, Sprint cadence and how that aligns with release planning).
Since it's not addressed in Scrum, the best conclusion that I've been able to draw are that this type of work must be done to some extent before the first Sprint of your Scrum process begins. The extent to which they must be done would vary depending on your organization and the product or service being created and delivered. Once you understand what you must do, you can timebox this effort. The only data that I've found on this is a (very) small (and probably not statistically significant) survey by Scott Ambler where he found the average inception work lasted about 4-5 weeks. If you're onboarding a new team to an existing product, it will probably take less time. If you're starting greenfield development in a highly complex environment, it may take a little more.
You may be interested in the Disciplined Agile definition of the Inception phase, as well. It has a number of goals and outcomes that would lead into what DA calls the Construction phase, where Scrum as it's defined in the Scrum Guide is one possible framework for implementing those activities.