Story Points Explained. Part 2: Size-based estimation

In part 1, I explained (I hope) the need for complexity/size based estimations.
In this part I wish to explain how story points work, and why.

Story Points are an arbitrary value assigned to a story (feature, business task, etc.) based on its complexity relative to other stories. There is no direct correlation to time, nor should you attempt to make one. This means, you should never try to say "Hmm, in a fifteen day sprint we can do 45 SPs, therefore 3 SPs are equal to 1 day, so if I can do this in half a day, it's worth 1.5 SPs".

What should be going through your head is: Hmm, this story not very easy, nor is it difficult. It seems to be about as complex as that story which we estimated to be 3 SPs. So I'll call it 3 SPs as well.

For the release planning (i.e. when you prioritize stories for the next few sprints) this is good enough. It doesn't matter how much time something will actually take. The PO can decide whether to descope, and whether to implement earlier or later, merely based on relative complexity alone!

During the Sprint Planning session, each story is broken down (by the team, for the team) into development tasks, which are small enough to be able to estimate in time with sufficient accuracy. They add up the time, and keep taking tasks (stories) until they reach the amount of time they have to develop (number of work days in a sprint, minus pre-planned abscences, etc).

When they reach the limit, the team knows how many stories they can do in a sprint, and commit to that. At the end of the sprint, the sum of the story points of the stories they completed is their velocity (story points per sprint).

The sum of the unimplemented stories' story points remaining in the release backlog, divided by the velocity is the number of sprints before the requisite features will be done, and the time until they can be released.

This solves the PO's need to set the next version's release date (Look ma, no time!)!