By tracking team velocity over time, teams will begin to focus less on utilization and consequently more on throughput.įor teams without a stable velocity, each team member should provide three simple measures to determine capacity. Derive team velocity by summing the story point estimates of all completed and accepted work from the previous sprint. Determining Velocityįirst of all, as velocity is unique to every team, never use another team’s velocity to plan your sprint. In these cases, new teams may need to make forecasts based solely on the their capacity. However, new teams may not know their velocity or they may not be stable enough to use velocity as a basis for sprint planning. To calculate a commitment, mature teams may use a combination of both team availability and velocity.

Therefore, stories should not be incomplete or process-based as a horizontal slice. Additionally, each story must be able to stand on its own as a vertical slice. Rather, in order to consider for sprint planning, split the stories into smaller pieces. In these cases, do not consider these stories as valid sprint backlog candidates. Ensure Right Sizing Backlog Itemsīased on historical data of the team, first determine if product backlog items are too large to complete in a sprint. All stories must be verified that they are implemented to the satisfaction of the Product Owner. Product backlog items (PBI’s) must be small enough to complete during a sprint and should be small enough to complete within a few days. The product backlog can address just about anything, to include new functionality, bugs, and risks. In the days and weeks leading up to sprint planning, the Product Owner identify the items with the greatest value and works towards getting them to a ready state.

How do we prepare?Įnsure all sprint candidates meet the team’s definition of ready. Sprint planning is a collaborative effort involving a ScrumMaster, who facilitates the meeting, a Product Owner, who clarifies the details of the product backlog items and their respective acceptance criteria, and the Entire Agile Team, who define the work and effort necessary to meet their sprint commitment. This agreement defines the sprint backlog and is based on the team’s velocity or capacity and the length of the sprint. In sprint planning, the entire team agrees to complete a set of product backlog items. Sprint planning is a timeboxed working session that lasts roughly 1 hour for every week of a sprint.

Sprint scrum