Story Points Defined

For those unfamiliar with story points, I recommend reading Maarten Dalmijn's insightful article. He succinctly describes story points as a method for making relative estimates of the effort needed to complete a specific task, known in Scrum as a Product Backlog Item (PBI). In essence, story points serve a distinct purpose: when used correctly, they can be invaluable, but when misapplied, they become unproductive.

Misunderstandings surrounding story points have unfortunately led to negative perceptions. A simple online search reveals numerous critiques. This negativity is regrettable because, as I mentioned, when used effectively, story points can be a significant asset.

The Value of Story Points

In my view, story points serve as an effective means of breaking down work into manageable components—a crucial skill for Developers. This approach fosters a clearer understanding of tasks. As noted by Dalmijn, smaller work items typically carry less uncertainty.

This skill has several implications. For instance, it streamlines Sprint planning, allowing the team to more accurately gauge their workload. This precision supports a smoother workflow, mitigating the last-minute stress that often accompanies Sprint deadlines.

While we might wish to embrace a more fluid approach with the mindset of “it will be done when it’s done,” this isn’t always feasible. Even from an Agile viewpoint, it’s beneficial to have a rough idea of what can be accomplished within a given timeframe. Projects that span years will naturally be approached differently than those that can be completed in days.

It's crucial to recognize that estimates merely provide a rough outline. In this context, estimation functions more as a prioritization tool rather than a strict planning mechanism. This distinction is vital, as it shapes conversations significantly:

"If this task will take several months, let’s prioritize this other task that we’ll need in a year—there’s enough buffer time to complete it."

versus:

"This task has a deadline in 61 days, but we’re falling behind, so we need to consider overtime."

Additionally, learning to prepare work allows for smoother collaboration. Tackling a single PBI as a team can be challenging, often limited to pair programming, which can be inefficient. Dividing a PBI into smaller segments enables multiple Developers to contribute simultaneously, enhancing focus and fostering ongoing alignment.

Story Points as a Learning Instrument

So, how do story points facilitate the learning process for preparing work? They provide a straightforward way to visualize task size, creating an ideal feedback loop for understanding how to break down work effectively.

You might wonder how this works, given that story points are relative and not directly tied to absolute time. It’s simple: a team commits to completing a certain number of story points in a Sprint. If they fall short, it indicates their estimates were overly optimistic; if they exceed their commitment, their estimates were too cautious. With repeated Sprints, the team begins to intuitively grasp what a story point represents.

In my experience, it can be even simpler. At the end of a Sprint, if the team hasn’t met their commitment, they naturally identify the PBIs that took longer than anticipated. This reflects their pride in their work and desire for excellence.

Yes, it’s instinctual, but that’s completely acceptable. The focus should be on learning from mistakes rather than achieving pinpoint accuracy. The greater the team’s estimation errors, the more they can learn from their experiences.

If you’re concerned about the implications of a team missing its commitment, remember that this perspective is output-driven. The success of the Sprint hinges on achieving the Sprint Goal, not merely a specific volume of work. Prioritizing the goal provides the team with flexibility, allowing room for growth in this essential skill.

Ultimately, story points are not about being right; they are about learning from the process. This is a liberating realization, as it means we don’t need to take the task too seriously. Whether a point is assigned a value of 3 or 5 should be secondary; the key discussions occur afterward when we evaluate whether we’ve met our commitments.

Understanding that learning flourishes in a gamified environment presents an opportunity. I personally favor bucket estimation over traditional poker sessions. This method involves setting up a table with the Fibonacci sequence and inviting team members to place PBIs in the column they believe is correct. Framing it as a game—perhaps adding a playful prize for the most items moved—encourages laughter and engagement.

What results is a lively session where estimation occurs rapidly. I’ve witnessed teams estimate 40 items in just 10 to 20 minutes, including discussions.

Conclusion

In summary, story points offer a simple tool driven by intuition and team dynamics. Through the feedback loop provided by Sprints, teams gradually learn to decompose their stories into smaller units, ideally below five story points each.

Once this level of proficiency is achieved—estimations of 1, 2, or 3 story points—the need for story points and commitment may fade.

But there’s more. The valuable skill acquired by Developers enables them to estimate tasks more reliably, whether it’s a specific functionality or an entire project. The rule remains:

"The larger the item being estimated, the higher the margin for error."

Consequently, these teams often forego traditional refinement sessions in favor of brainstorming activities that break down work and yield even more accurate estimates.

Who would have thought that story points could be both useful and enjoyable? By framing the process as a game, we tap into the team’s motivation to excel, whether in achieving their commitments or Sprint Goals.

Imagine the moment you inform your team:

"Congratulations! You no longer need story points or commitments. You’re achieving what many believe is impossible!"

Special thanks to Phil Ledgerwood for his insights on Kanban and Little's Law.