How do you estimate a release date?

If you're making relative estimations for your product backlog items - how can you possibly know when things are released? The answer is velocity. And with velocity I mean the number of story points you can finish in a sprint. And how do you know that? Experience.

This is how you play the game: You create a product backlog with a number of stories. You give each story an estimate.

What happens next is up to you. You can try calculating a velocity by turning to the good old Golden list and look at the items there: how much work was put into those actual tasks? You will probably need to recalculate if it's a different team or if other stuff has changed but since you're in to software development, the maths are probably not your softest spot. So now you have an appropriate number. Say you looked at some items and find out that based on the team and sprint length and all those factors, a figure could be 27.

Ok. 27. Do you believe that 27 is what the team can accomplish during a really bad sprint, an average sprint or a brilliant sprint? Place that number in the appropriate box and simply guess what the number based on that should be on the other types of sprint (bad, average, good). You can of course ask some other guys as well but now you don't know too much. You don't know how well the team works together, if the development environment is good, if the customers and stakeholders will deliver material in time and all that stuff. And what you do now is get the people responsible together and ask the simple question: will this be worth it? You can now from your vague intuition on scope and velocity give a very very rough estimate on how much everything will cost and when you'll be done. If people still are on the train, you can get going but this is a very important time because now the people paying the bill can see some kind of prognosis of how huge this project is. And how much it will cost.

If they are still Ok with paying the bills, you can start your first sprint and this is the first oppertunity for changing your rough plan because now they will commit to the stuff on top of the product backlog and now you can see what your 27 was worth. Let them take on what they feel they can handle. Don't push them to take on more. Don't hinder them if you believe they've taken on too much. Let them commit.

After that first sprint you take note of the number of story points finished during the sprint. And you do the same for the coming five. And now you can really start to get a feeling for your velocity. Take the lowest two results and take the average. This is your minimum. Take the middle two and do the same. This is your average. And then you take the top two. This is your max. For example:
22
20
28
30
12
40

This would give you a min of 16, average of 25 and a max of 35.

OK. What you do now is that you go back to your product backlog and then you look a head for the next 4 sprints. And you see how much lies under 16*4. This is what you can count on being fixed during the next four sprints. The stuff that is under (25*4)-(16*4) is decreasingly probable that it will be fixed and then you can just increase the improbability. What is over 35*4 is certainly not going to be fixed, if nothing else changes.

So what you can do now is go to your stakeholders and present the information just like this: this we will do, this can be done and this will probably not be done. They will probably change their priorities a bit and this is the objective: getting them to decide how sure they want to be to have something within a specific time frame. And to understand that this is a numbered list: if something goes up, something else drops down. Working like this makes it obvious and if it still isn't to your stakeholders, use some visual effect like postits that you move up and down to make it clear what prioritization is. The hard part is not saying what you want but saying what you don't need as much.