Skip to content

Sizing

Points Don't Matter

When it comes to determining how much work can a team bring in during a sprint, teams need to have a common base understanding of the time, difficulty, or complexity of the story. Proper sizing enables the team to increase flow, minimize rework, and stablize velocity. It is easier to determine the relative complexity of a task rather than figuring out how much time it requires.

Story pointing

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 able to be completed in a day. Pointing becomes a simpler task as teams mature and more knowledgeable about story splitting.

Fibonacci technique

Fibonnaci

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. (source)

As team's adopt relative sizing, they must come to a common understanding of what a base unit of work is- a 1 point story. 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.

What is a spike?

Teams often mistakenly refer to spikes as research. Originated from eXtreme Programming (XP), spikes are a very simple solution 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.