Requirements

Getting started, the Product Owner goes over completed items from the last sprint — the done assignments scheduled previously and sees the results / achievements. Later on, it’s important to review other assignments that are still in progress and know their status. Ideally, the Product Owner will have to make questions about these ongoing stories, requesting why they haven’t been completed as expected.

Though the final Sprint Goal is a product of the efforts of the whole Scrum Team, the Product Owner should come prepared with an initial objective. What will be the objective of the Sprint and how does that add to the overall big picture of the project? This is important because it explains why this Sprint and everyone's work in it are important.

After defining the objective, the Product Owner goes over which backlog items will best support that objective — what will become the Sprint Backlog (after discussion and negotiation with the rest of the team, of course). Ideally, the Product Owner will have prepared two sprints’ worth of product backlog items.

Now it’s time for the Product Owner to break down the requirements of each user story, in other words, the acceptance criteria. What are the specifics regarding functionality, from the user’s point of view? The acceptance criteria should eliminate any ambiguity surrounding a user story, so that the team can move forward with a clear picture of what they’re creating in the upcoming Sprint.

Here’s a mini Agile refresh: The first Agile value emphasizes “individuals and interactions.” Thus, it’s so important that the Sprint Planning meeting isn’t an unloading of orders. At its best, Scrum empowers every team member to play an active part in Sprint Planning.

This is a team effort that involves the Product Owner and the Development Team. Are there dependencies that haven’t been identified? Are any of the proposed items too large to fit into the next Sprint? Can it be broken down? This step is where story points come into play — another reason why it’s helpful to estimate story points. Story points are numbers that assign value to the amount of effort that a user story will require. They help the team gauge their work.

Team capacity is the total hours that the team can dedicate to working in the upcoming Sprint. Calculate this figure by adding up each person’s available hours, taking into account any time off.