Forums

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

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. If you have left the first and last name fields blank on your member profile, your email address will be displayed instead.

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. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Explaining definition of story points to the dev team
Last Post 16 Nov 2013 06:47 AM by Florian Straub. 1 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages Not Resolved
Florian Straub
New Member
New Member
Posts:8
Florian Straub

--
16 Nov 2013 06:13 AM
    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
    Florian Straub
    New Member
    New Member
    Posts:8
    Florian Straub

    --
    16 Nov 2013 06:47 AM
    moved to https://www.scrum.org/Forums/aft/539

    please delete

    Sorry,

    Flo
    You are not authorized to post a reply.


    Feedback