Thus sizing these User Stories, without much insight of functional details, requires an specialized sizing and estimation process beyond conventional estimation techniques in which project managers dig deep into requirements and come-up with their near to actual time estimates.

Size vs Duration
Scrum development process inventors have come up with a creative idea of dealing with this problem. They have divided Time estimation of a project in two parts, Size and Context.

Let’s look at it as:  Time = Size x Context.  Thus for story sizing process in sprints we focus on the Size only (because Context is never completely known), However Context is being discussed only, and Time is calculated by someone who is actually going to do the job later when user stories are assigned to developers.

Let’s take an example to understand the difference more.

Example: Let's say that one programmer can develop a story in two weeks. Same story can be developed by two programmers in only one week.

Notice that Time of completion of this story is decreased, in Context of how many developers are working on it. However the Size (Complexity) of the story remains the same in both situations.

Sizing this Complexity is called Story Point Estimation.

Story Points
For this story size estimation, we use Story Points. Story points are just numbers attached to individual stories that represent estimate of Size only of a User Story. We do discuss Context while sizing, but we don’t try to come-up with resulting time required.

In other words Story Points are a measurement of complexity and/or size of a requirement as compared to the Duration to complete that requirement.


Agile vs Waterfall Methodology
Understanding Point based system is a paradigm shift, because previously we are trained by development processes like waterfall, to come up with a detailed project plan in number of weeks and days. However we should not forget that in agile project we don’t have detailed requirements at the time of story size estimation stage.

Point-based estimation methodology is a step away from answering "how long will it take" to address the more critical first question of "how big is the job”, because agile story points do not relate to time but only to the absolute size of a user story. Story Points have nothing to do with who is implementing it and how long it's going to take.

Point Scale
The Scale selected for assigning Points to each story can vary from team to team. Some teams use Fibonacci series as their scale for estimation method, others may come up with relatively simple scale e.g.

0, 1, 3, 5, 8, 13, 21, 40, 75, 100, Infinity

Difference between two points in our scale should be relative (0, 1, 3, 5 .. ) rather than absolute (1, 2, 3, 4, ..). Absolute scales will again force us to go into functional details for the estimation, before choosing between the two consecutive sizes.

Also Scale should have enough points to easily estimate User Stories of varying complexities.

Why Use Story Points
You might be asking yourself, ok Story Estimation is the only way to Size the stories in Agile, but why would I use this technique? What’s in it for me? Actually everything, if you are a project manager or if you are the one to come-up with an insight into how much time is left before project completion.

With Story points you will have a better idea of how many points your team can complete within one sprint, thus simple calculations of remaining Story Points in backlog divided by Points completed in one sprint will give you the number of sprints project will take. From Number of sprints you can comfortably get number of weeks required, by simple multiplication with size of your sprint.

In this tutorial we only looked at what is Story Point Estimation, what a Story Point Scale looks like and potential benefits of Story Points Estimation technique. Assigning Points to User Stories by agile teams is a technique in itself and out of scope of this tutorial.