What are story points?
When the team is reviewing the backlog and planning their sprint, they will begin to undertake the process of estimating for each user story so that they can define the work that will take place during the sprint.
Many developers and teams have extensive experience estimating how long coding a requirement will take. Traditionally this has taken the form of estimating how many hours it would take to code each requirement…and traditionally this method did not work very well.
Scrum varies the formula by asking that the team assign story points to each user story. These story points are a measure of the complexity of each story. They do not attempt to assign duration to each story, but instead allow a comparison between tasks.
You may ask why you shouldn’t assign hours to a user story. The reason is simple…each developer codes at a different rate. Having the team assign hours to a story assumes that they all can code at the same speed. Also, by estimating the complexity of each story, you have created a way for the team to analyze the stories from a more abstract vantage point. This can help to reduce bias during the estimating process.
As product owner, I need to have some level of comfort that the team can keep their commitments. If there is no estimation in hours, then how do we know if the team can complete all of the work they have committed to?
The story points are used to reflect complexity of a task, and over time the team gets very good at translating story points into approximate hours. Also, some teams that are starting with Scrum have the developers replace the measure of complexity with estimate of hours when defining story points.
If you keep up the estimation meetings and get the same team to estimate the story points you normally get an approzimate number of story points for the team per sprint.
I think the important thing is that it is only the team who are actually doing the work (developers, testers, architects) do the estimate of story points. That they realise that the estimate is for the whole teams work, so they may have to explain why a chunk of the work has a high number of story points associated.
Crucial in my opinion is that the team does not feel under pressure to say something is easy/hard because they are told it is easy/hard. Tell the team what the story is and let them estimate the story points without anyone telling them it must be a few or many story points.