When it comes to determining how much work a team can bring in during a sprint, teams need to have a common base understanding of the time, difficulty, or complexity of a story. Proper sizing enables the team to increase flow, minimize rework, and stabilize velocity. It is easier to determine the relative complexity of a task rather than figuring out how much time it requires.
Story pointing is an exercise that is completely relative to a team. Rather than determining capacity or tracking hours, points serve the purpose of determining how much risk is represented in accepting a story. Elements that impact estimation are:
- uncertainty
- complexity
- security risks
- size
- dependencies
?> Stories points should continue getting smaller and should be able to be completed in a day. Pointing becomes a simpler task as teams mature and become more knowledgeable about story splitting.
People estimate stories with smaller points more accurately than stories with higher points. As the numbers increase, the difference between two succeeding numbers increases exponentially and leads to less accurate estimates. This is intentional, as most stories are often more complex than we realize.
As teams adopt relative sizing, they must come to a common understanding about the size of a 1 point story, the base unit of work. Activities like agile poker allow teams to collaborate, giving each team member to voice their opinion on how stories should be pointed and establishing the team's baseline of relative sizing.
Teams often mistakenly refer to spikes as research. Originated from eXtreme Programming (XP), a spike is a very simple program to explore potential solutions. Spikes are experimental in nature. They should answer a specific question and should be timeboxed. The result should be a prototype, not a document.
Spikes represent a trade-off between a need to answer questions and a need to produce features. Product owners and delivery teams should carefully consider how much time and energy to devote to spikes, ensuring that the time is spent creating value by solving a technical problem or reducing uncertainty.