How long should we time box the prep time before the first sprint starts – i.e. the time used to decide on a product that has a good chance of meeting the goals, make effort and business value estimates and get the top product backlog items to be sprint ready?
I would look for the shortest time you can to prep. To get started in a sprint you need a team and a product backlog. You don’t need a complete and perfect product backlog – since more product backlog items will get added as you go along and existing items will be altered and sometimes removed. I would start working and refining the backlog as you go – so you don’t end up with a “design sprint” that takes longer than a sprint itself.
The 2017 Scrum Guide outlines that up to about 10% of the development team’s capacity will be used in backlog refinement activities. These activities are ongoing and collaborative between the product owner and the development team. The scrum team decides how and when refinement is done. In the initial sprints, that activity might look like several backlog refinement meetings to get the backlog to a state where there are 2-3 weeks of sprint ready product backlog items. After that it may look like one refinement meeting per week and the development team members doing research, prototyping, etc. to get information to refine the product backlog items.
I would start with the vision, have some product backlog items prioritized in the product backlog, and do a few product backlog refinement sessions to get them sprint ready. They don’t have to be perfect – smaller is better. The question to ask in the session: What’s the smallest piece that could be delivered to get feedback which is still a deliverable? For the product backlog items farther down in the backlog – they can be big, with a swag estimate and a general idea. Then as they are moving up, they need to be split, have new acceptance criteria, and be estimated.
Sprint ready product backlog items are items which can reasonably be “done” in a sprint according to The Scrum Guide. For the best chance of this, I find it useful for sprint ready product backlog items to have four components:
1. They are small enough to be completed in a sprint
2. They have agreed upon acceptance criteria
3. They have an estimate
4. They have no outstanding dependencies
Mostly, the idea is to get the shortest feedback cycle possible in a way that works for your teams so the scrum team can begin seeing real product and getting feedback from stakeholders to make sure they are on the right track.