Plan A Sprint

(Activity) for Tier: Sprint

PURPOSE

Sprint planning is a collaborative negotiation between the development team and the Product Owner about what the team will do during the sprint. When performed, sprint planning will result in an agreed upon sprint backlog and team commitment for completion of assigned product backlog within the agreed upon sprint time-box.

WHEN

Continuously.

INPUTS

ENTRY CRITERIA

  • Product backlog is appropriately stack ranked.
  • User Stories have met the INVEST criteria.

SUB-ACTIVITIES

  1. Call Sprint Planning Meeting(s)

    • Team facilitator, typically the Scrum Master, invites all appropriate stakeholders, scheduling a team meeting or a series of meetings.
    • Reference the team’s norms to determine the method of recording meeting minutes.
    • The facilitator will kick off the meeting by recording attendance.

  2. Define the Sprint

    • Discuss the highest priority needs of the customer and how those needs are reflected in the product backlog.
    • Review the team’s definition of done for user stories. The goal is for the team to agree on what it means for a user story to be “done”.
    • Review product backlog to ensure each user story is ready.
    • Review each user story starting with the highest ranked item, continuing until the team agrees that they have reached capacity for the sprint. Consider using your historical average velocity, upcoming planned leave and/or holidays.
    • Record discussion notes relating to user stories within the stories themselves.
    • Assign each work item to the planned Iteration Path.

  3. Commit to Sprint Backlog

    • The team creates an initial list of tasks needed to achieve “done” for each user story assigned to the planned iteration path. If necessary, break into smaller teams to finish creating tasks.
    • Use subject matter expertise to estimate the amount of work required to complete each task. Record the estimate on each task within the Original Estimate and Remaining Work fields.
    • Ensure the total estimate doesn’t exceed the team’s capacity. Hours and story points are common ways to assess this. Also consider the quantity of stories and bugs as each one incurs a coordination cost that may not be apparent.
    • Consider if any user story original story points value should be adjusted based on significant deviations. In other words, if after creating tasking you determine the implementation is of a significantly lower level of effort than originally expected, then you might have leftover capacity in the sprint and may need to add items to the sprint backlog. Inversely, if you significantly underestimated the level of effort to complete a user story, and it is much larger than originally expected then you may need to remove items from the sprint backlog.
    • Remove any items from the iteration path that exceed the team’s capacity.

EXIT CRITERIA

The team has committed to a sprint backlog based on available resources and team members’ capacity.

SEE ALSO

Process Guidance Version: 10.4