The last time Hackerfall tried to access this page, it returned a not found error. A cached version of the page is below, or clickhereto continue anyway

Story Points and Sizing Complexity –

One of the most important tools in the Agile Development toolbox is point-based sizing of user stories. In contrast to time-based estimation (i.e. hours and days) points are used to estimate sizes in a relative way. Two stories of equal size are expected to have equal points

While this sounds nice in theory, its hard to get an intuitive feel for what that means. What is a point? What criteria do we use to establish our point size? If you ask 10 agile teams about their sizing criteria, youll probably get 10 different answers. Some use effort, others technical complexity. Sometimes points are not even numerical but rather Small, Extra Large, or even Cat, Dog, Cow. Especially in teams that are just starting to use point-based sizing there can even be differences in criteria within the team.

Before diving in to a few ways to develop an intuition about relative sizing, lets start with briefly reviewing the benefits of using points.

Time-based Sizing is Problematic With time-based sizing, the false impression of accuracy can be a significant issue. If I ask a developer for a time estimate, and she tells me its going to take 4 hours, I may imagine that I could reasonably expect that the task will be completed 4 hours after she starts. Unfortunately, this is rarely how it really works.

Especially in software development, the variation between estimates and reality can be very large. While a 400-hour project might take 500 hours to complete, a 1-hour task can just as easily take 5 hours to complete. Thats a 400% increase compared to 25% for the larger project. The estimation error is not necessarily relative to the original estimate.

Team estimates present another set of issues with time-based sizing. While the best estimators (I have yet to find one) might be fairly accurate in estimating their own work, their reliability generally disintegrates when trying to estimate the required effort for a team. Time-based estimates are dependent on who implements a task, the technology used and the state of the codebase, rate and length of interruptions, previous experience with similar problems, along with myriad other things that vary wildly across people and tasks.

A third problem is psychological in nature. If 4 hours are estimated for a task but Im done in 2, I often feel like I missed something. I dont want to deliver my work with time to spare, so I take a step back and look for improvements. Finishing early a number of times might have future estimates adjusted downwards, but until then, I’m not as productive as I might have been. Time-estimated tasks tend to converge towards the estimate, and not towards the optimal amount of effort.

All things considered, time-based estimates are terribly inaccurate when predicting the duration of a single task done by a single person. They’re even worse when forecasting team results.

Point-based Sizing Addresses Many of these Issues Point-based sizing on the other hand does not aim for individual accuracy. In particular, the ambiguity regarding what constitutes a point makes it impossible to assess whether a single story will be exactly 5 points or not.

Instead, points shine when aggregated over a larger number of stories. Points get their true value from empirical evidence. Over the past N sprints we were able to deliver X points. This metric is referred to as the velocity of a team.

The lack of a readily measurable quantity that represents a point makes it challenging to estimate in points. Teams should find a common framework of what to include in their estimation, and above all, remain consistent over time.

Qualities of a point As we’ve been discussing, it is difficult to describe points in terms of measurable qualities. The understanding of what constitutes a point will differ from team to team. Instead, what we can do is describe what points should not be. Looking at the drawbacks of time-based estimation, we can state that points should not:

What remains is a sizing framework unique to your team, but one that focuses on the intrinsic complexity of each user story instead of that of implementation details.

Each one of these properties will almost certainly have an impact on the number of hours a story will take to implement. Therein lies the difficulty inherent in attempting to account for these factors when estimating each story individually. A more fruitful approach is to accept their impact on the overall velocity, while focusing on the number of stories that can be completed in each sprint.

Using this framework, we can clearly improve our productivity by addressing the above items individually. By improving, for instance, the maturity of the existing code, we can measurably increase our velocity by delivering more points each sprint. This approach helps the team find bottlenecks and improve them by focusing on the question: How can we increase our overall velocity?

Using these guidelines means that sometimes implementing a story today can mean that that takes multiple sprints, while doing the same story later when there are more building blocks already in place, might require significantly less effort. While at first this may seem counterintuitive, this is exactly how we want to use points. Having those building blocks in place means a direct increase in velocity, and in turn, increase the capability to deliver more stories, faster.

Point-based sizing allows teams to focus on the important aspects of their stories and reduces the overhead of estimating tasks, while still providing meaningful metrics for velocity and accomplishments for each sprint.

Continue reading on