Explaining definition of story points to the dev team

Hi all,

we've spent 12 sprints with planning poker and story points based on complexity. Our new scrum consultant said, that complexity as a measured variable/unit is still too time related and that people are still thinking in effort and time for implementation.


I think that he's right, since we used to determine the story points per day/person during our sprint planning to determine the amount of story points to pick. This is probably not the "spirit of scrum" ...


Our scrum consultant suggested to not consider story points in planning at all, but to ask the team after introduction of each story if they think that they can do it within the sprint. As far as I got him, story points are only used by the product owner in order to update the release plan with the teams velocity. And they're probably used by the scrum master in order to see performance changes.


What I liked about the consultant's suggestion is that they recommended to have three 30 minute estimation meetings during a two week sprint where you estimate the whole backlog each time. With this method people will probably be forced to deal with all items all the time. This will probably raise the awareness for and the quality of all backlog items.


The consultant recommended using magic estimation. We should compare the user stories relative too each other by guessing/estimating/measuring/imagining the number/amount of problems that the story solves for the customer. As an example he said that a nail solves less problems for a customer than a hammer which solves less than an electric drill.


I wasn't really able to transfer the idea of this measured variable/unit to the dev team, probably because I wasn't completely convinced either. They asked why they should determine the amount of use for the customer. This should be the po's job, they said.


I found some other suggestions online which recommend using t-shirt sizes or the level of understanding for a story. Our management (which introduced scrum and promotes it) said that level of understanding isn't enough, since you could also understand something that solves a lot of problems.


My questions:

1. Did I get the whole idea right?

2. Which measured variable/unit can be used for estimation?

3. How do I transfer that idea to the team?

4. Are there any other things that I overlook here?


Thanks in advance,

Flo