Sprint planning is one of the most important meetings to product and tech teams, and indeed the company more broadly — particularly for early-stage and growth businesses, where laser-like focus on building the most important features to deliver the highest value is key.
Since this meeting will define what a scrum team will be dedicating their efforts towards over the coming cycle (usually 2 weeks), it is quite normal for this to be a longer meeting than others, to allow enough time for questions on requirements and discussion over prioritisation, as well as all the relevant administration of marshalling the troops.
In attendance should be all scrum team members — product manager/s, designers, engineers, QA — as well as related support roles like product marketing and analytics. You may also wish to include a small number of representative stakeholders from the business more broadly, if they are needed to give context to requirements or priority decisions. But this is primarily to observe, and numbers should be strictly limited to ensure the meeting stays on track.
Ideally, the scrum team have a good sense of what is in the pipeline, prior to the meeting. The best software development teams involve design and engineering in solving the problem. This can take on a number of forms, but essentially, for work to be incorporated into a sprint, it needs to be reviewed with engineers to understand the complexity and effort involved. This can be achieved with earlier grooming sessions, where detail is fleshed out, questions answered and the specific approach to completing the work is roundly agreed, as well as the size estimated. But if not beforehand, then it must happen in sprint planning.
Watch out though — if dev teams are only seeing high-level requirements for the first time in sprint planning (and on multiple tickets), then meeting length can push out. Insert five minute breaks every 45 minutes or so to make sure attendees don't get worn down!
For Meetric users, we recommend using this template as follows: