Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

Explaining definition of story points to the dev team

Last post 07:47 am November 16, 2013 by Florian Straub
1 reply
07:13 am November 16, 2013

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,


07:47 am November 16, 2013

moved to

please delete



By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.