One of the fundamental differences between traditional waterfall delivery and agile delivery is planning.
Planning is performed upfront with an entire view of scope and an end date, typically defined by management.
Planning is performed iteratively and continuously, assessing the need to adapt to emerging needs and changes. [1]
The most common practice in planning is to use velocity to determine capacity using Story Points.
Velocity-based planning is based on the premise that the amount of work a team will do in an upcoming Sprint is roughly equal to what they have done in prior Sprints. [3] Various assumptions are made such as a constant team size, risk, complexity, similar type of work, consistent Sprint lengths, etc.
To utilise velocity-based planning the team needs to have baseline data to form assumptions around the anticipated future velocity of the team. Hence, Story Point estimation plays a greater role.
Velocity changes over time, so avoid relying on:
Try, instead, to calculate what velocity is achieved 80-90% of the time.
The Scaled Agile Framework® (SAFe®) recommends a normalisation approach to forecasting velocity and planning in teams [5]:
Example
Assuming a six-person team composed of three developers, two testers, one Product Owner and one Scrum Master, with no vacations, then the estimated capacity equals:
“Don’t look back”
Once the team starts Sprinting, start measuring planned versus actual velocity. Replace the old velocity with the new, actual numbers, for future planning. Importantly, don’t adjust old figures or re-estimate old Backlog items based on your new data.
Be aware that planning out every Sprint for an entire quarter introduces significant uncertainty, even if just from the perspective of natural variability. The futher our the team forecasts their load versus capacity the more likely their estimations will be inaccurate.
Ensure that the forward plan for Sprints is adjusted each Sprint Review and expectations set with stakeholders and the Product Owner regarding what can be delivered and when.
People are tempted to ensure each Sprint is "full" so that the team is "fully utilised". When a whole quarter of Sprints is full, there is no room to take on feedback at the end of each Sprint. Ensure that there is some capacity to take on feedback and adapt each Sprint. If a Sprint isn't full, but the team finishes early, then it can simply take on more work directly from the Product Backlog.
All fields are required.