When does a Scrum Team assign story points to the stories in the Scrum methodology?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP

up vote
8
down vote

favorite

1

I am in the process of learning Scrum. I got stuck with a question: on which stage does the Scrum Team assign story points to the user stories?

share|improve this question

  • For the record: while the answers below are all fine, it should be noted that story points are not a part of Scrum, so their use is not required. This is also the reason you can’t simply answer this question by reading the scrum guide.
    – Erik
    Nov 29 at 10:08

  • 1

    Good to know that @Erik
    – jithin
    Nov 29 at 10:13

up vote
8
down vote

favorite

1

I am in the process of learning Scrum. I got stuck with a question: on which stage does the Scrum Team assign story points to the user stories?

share|improve this question

  • For the record: while the answers below are all fine, it should be noted that story points are not a part of Scrum, so their use is not required. This is also the reason you can’t simply answer this question by reading the scrum guide.
    – Erik
    Nov 29 at 10:08

  • 1

    Good to know that @Erik
    – jithin
    Nov 29 at 10:13

up vote
8
down vote

favorite

1

up vote
8
down vote

favorite

1
1

I am in the process of learning Scrum. I got stuck with a question: on which stage does the Scrum Team assign story points to the user stories?

share|improve this question

I am in the process of learning Scrum. I got stuck with a question: on which stage does the Scrum Team assign story points to the user stories?

scrum agile user-stories story-points

share|improve this question

share|improve this question

share|improve this question

share|improve this question

edited Nov 30 at 7:09

tiagoperes

33318

33318

asked Nov 29 at 8:29

jithin

434

434

  • For the record: while the answers below are all fine, it should be noted that story points are not a part of Scrum, so their use is not required. This is also the reason you can’t simply answer this question by reading the scrum guide.
    – Erik
    Nov 29 at 10:08

  • 1

    Good to know that @Erik
    – jithin
    Nov 29 at 10:13

  • For the record: while the answers below are all fine, it should be noted that story points are not a part of Scrum, so their use is not required. This is also the reason you can’t simply answer this question by reading the scrum guide.
    – Erik
    Nov 29 at 10:08

  • 1

    Good to know that @Erik
    – jithin
    Nov 29 at 10:13

For the record: while the answers below are all fine, it should be noted that story points are not a part of Scrum, so their use is not required. This is also the reason you can’t simply answer this question by reading the scrum guide.
– Erik
Nov 29 at 10:08

For the record: while the answers below are all fine, it should be noted that story points are not a part of Scrum, so their use is not required. This is also the reason you can’t simply answer this question by reading the scrum guide.
– Erik
Nov 29 at 10:08

1

1

Good to know that @Erik
– jithin
Nov 29 at 10:13

Good to know that @Erik
– jithin
Nov 29 at 10:13

4 Answers
4

active

oldest

votes

up vote
14
down vote

accepted

The only certain answer is: sometime before the story is added into the sprint. After that the story point estimate doesn’t add much value.

Common times that Scrum teams estimate stories:

  • Backlog Refinement: In backlog refinement the team looks one or two sprints out to see what is coming up and prepares these stories to be brought into a sprint. Estimation is a common thing to happen here because the act of trying to estimate the story often brings out details about the story.

  • Release Planning: This is a planning that takes a high-level look at the next few months and I’ve worked with many teams that take a first-guess estimate at all stories in the release planning. It is understood in these teams that these estimates are rough guesses used for general planning purposes and they usually revisit the estimates in a Backlog Refinement closer to actually working the item.

  • Sprint Planning: It isn’t common practice anymore to estimate right at sprint planning, but it still happens sometimes. Usually, this happens with stories that emerge right before the sprint (maybe a gap discovered in the last Sprint Review). This estimate is usually done at this time in order to weigh the cost/value benefit before deciding to bring it into the sprint.

share

    up vote
    4
    down vote

    A story point number is the outcome of an estimation of a user story, so story points are assigned when the team estimates the stories.

    The latest point in time where estimation can/should be done is when a story is being considered for inclusion in the current or upcoming sprint. This is normally during the planning session.

    A more common point to do the estimation is during a backlog refinement session once the team feels that the story is clear enough and small enough that they can start working on it and complete the story within one sprint.

    For long-term planning, it can be useful to already assign a tentative estimation to stories and/or epics that need further refinement. Even such a tentative estimation should come from the team.

    share|improve this answer

      up vote
      4
      down vote

      User Stories aren’t part of Scrum

      User Stories are an Extreme Programming (XP) practice. (see this question)

      However, every Scrum team I’ve worked with so far has used Extreme Programming practices alongside scrum.

      This blog on scrum.org has a pretty good explanation:

      Scrum does not mandate the usage of Planning Poker and Story Points.
      That is right. Planning Poker and Story points are actually not part
      of Scrum. This is the common misconception people have about Scrum
      that I have found in the community. Scrum Team is free to choose how
      they want to estimate. In fact, Scrum team is allowed to estimate in
      hours if they wish. Scrum Team who is practicing XP will do Planning
      Poker with Story Points every Sprint Planning.
      Many Scrum Team found
      this Planning Poker practice with Story Points is helpful.

      While the blog seems to imply that XP wants you to play Planning Poker each Sprint Planning, the XP rules don’t talk about Planning Poker at all. They do describe making a time estimate at the moment a User Story is written.

      There are no strict rules. Feel free to chose what works best for your team. In my personal experience, it works best to assign story points when creating the backlog, and reviewing them at the start of each sprint.

      share|improve this answer

      • User stories/tasks/cards/tickets ARE part of Scrum. However the Story points != hours is not part of Scrum.
        – slebetman
        Nov 30 at 2:55

      • Do you have a source on that? The Scrum Guide only talks about product backlog items. If you do have a source, please answer the question I linked, because the accepted answer there says User Stories are not part of scrum.
        – ONOZ
        Nov 30 at 12:02

      • You can call it “items” if you don’t want to call it product backlog stories – but they’re still tasks broken down such that a developer can pick it up and work on it. Different names – same thing. The cards/tasks/items/stories may have different feature sets depending on how the team work but they’re a core part of Scrum. I’ve worked on teams where “tasks” must be in the form of “As a <stakeholder role> I want <feature description>”. I’ve worked on teams where “stories” are just bullet points of feature requirements etc.
        – slebetman
        Nov 30 at 12:27

      • 1

        @slebetman the term is “Product Backlog Item” and they’re not really the same thing; stories are a specific implementation of a PBI, but a PBI can look completely different. They also don’t need to contain tasks; many of mine just contain the description of a problem that we’re supposed to tackle.
        – Erik
        Nov 30 at 12:56

      up vote
      1
      down vote

      This answer is structured in the following way:

      1. Example of a cycle for a two week sprint.
      2. Why story points?
      3. When to assign story points to the user-stories?

      The following image, taken from How to Kill the Scrum Monster: Quick Start to Agile Scrum Methodology and the Scrum Master Role shows an example of a meeting cycle for a two-week Sprint (Of course, all those meetings are not set in stone and can be adjusted based on need):

      scrum

      Planning (mandatory) meeting: The team plans what user stories (backlogs) it will execute during the Sprint and breaks them into tasks. The team commits to completing those during the Sprint according to the Definition of Done (DoD).

      Backlog grooming (optional) during execution of the Sprint N: The PO will introduce new backlogs if required and this meeting wil be an opportunity for the team to ask questions about backlogs for the next Sprint (N+1).

      Sprint review (mandatory): The ScMa and the team present to the PO all the backlogs that were committed this Sprint, and status according to the DoD.

      Retrospective (mandatory) team meeting: Team members discuss what went wrong, what went well, and if anything should be changed to improve team performance—also used as a meeting to release some steam. (Can be executed every second Sprint in case of short Sprints.)

      Scrum meeting or Stand-up (mandatory): short daily meeting where team developers answer three questions: What was done since the last meeting? What are the blocks? What will I be doing next?

      Now, Story points are estimates of effort assigned to user stories based on the amount of work, complexity, uncertainty, and risk.

      Eventually the team will learn how many story points it can take during a Sprint and it will be considered as team velocity. To measure the velocity, average of the last three Sprints can be used.

      From my experience, the story points were always given in the first day of the sprint, the planning meeting. Of course sometimes developers realize the story would actually be worth more / less story points (that is mentioned in the retrospective meeting) but generally speaking, because that’s a group decision and these conversations increase the team’s knowledge about each story, which will help to make the estimates more accurate.

      share|improve this answer

        Your Answer

        StackExchange.ready(function() {
        var channelOptions = {
        tags: “”.split(” “),
        id: “208”
        };
        initTagRenderer(“”.split(” “), “”.split(” “), channelOptions);

        StackExchange.using(“externalEditor”, function() {
        // Have to fire editor after snippets, if snippets enabled
        if (StackExchange.settings.snippets.snippetsEnabled) {
        StackExchange.using(“snippets”, function() {
        createEditor();
        });
        }
        else {
        createEditor();
        }
        });

        function createEditor() {
        StackExchange.prepareEditor({
        heartbeatType: ‘answer’,
        convertImagesToLinks: false,
        noModals: true,
        showLowRepImageUploadWarning: true,
        reputationToPostImages: null,
        bindNavPrevention: true,
        postfix: “”,
        imageUploader: {
        brandingHtml: “Powered by u003ca class=”icon-imgur-white” href=”https://imgur.com/”u003eu003c/au003e”,
        contentPolicyHtml: “User contributions licensed under u003ca href=”https://creativecommons.org/licenses/by-sa/3.0/”u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href=”https://stackoverflow.com/legal/content-policy”u003e(content policy)u003c/au003e”,
        allowUrls: true
        },
        noCode: true, onDemand: true,
        discardSelector: “.discard-answer”
        ,immediatelyShowMarkdownHelp:true
        });

        }
        });

        draft saved
        draft discarded

        StackExchange.ready(
        function () {
        StackExchange.openid.initPostLogin(‘.new-post-login’, ‘https%3a%2f%2fpm.stackexchange.com%2fquestions%2f25346%2fwhen-does-a-scrum-team-assign-story-points-to-the-stories-in-the-scrum-methodolo%23new-answer’, ‘question_page’);
        }
        );

        Post as a guest

        Required, but never shown

        4 Answers
        4

        active

        oldest

        votes

        4 Answers
        4

        active

        oldest

        votes

        active

        oldest

        votes

        active

        oldest

        votes

        up vote
        14
        down vote

        accepted

        The only certain answer is: sometime before the story is added into the sprint. After that the story point estimate doesn’t add much value.

        Common times that Scrum teams estimate stories:

        • Backlog Refinement: In backlog refinement the team looks one or two sprints out to see what is coming up and prepares these stories to be brought into a sprint. Estimation is a common thing to happen here because the act of trying to estimate the story often brings out details about the story.

        • Release Planning: This is a planning that takes a high-level look at the next few months and I’ve worked with many teams that take a first-guess estimate at all stories in the release planning. It is understood in these teams that these estimates are rough guesses used for general planning purposes and they usually revisit the estimates in a Backlog Refinement closer to actually working the item.

        • Sprint Planning: It isn’t common practice anymore to estimate right at sprint planning, but it still happens sometimes. Usually, this happens with stories that emerge right before the sprint (maybe a gap discovered in the last Sprint Review). This estimate is usually done at this time in order to weigh the cost/value benefit before deciding to bring it into the sprint.

        share

          up vote
          14
          down vote

          accepted

          The only certain answer is: sometime before the story is added into the sprint. After that the story point estimate doesn’t add much value.

          Common times that Scrum teams estimate stories:

          • Backlog Refinement: In backlog refinement the team looks one or two sprints out to see what is coming up and prepares these stories to be brought into a sprint. Estimation is a common thing to happen here because the act of trying to estimate the story often brings out details about the story.

          • Release Planning: This is a planning that takes a high-level look at the next few months and I’ve worked with many teams that take a first-guess estimate at all stories in the release planning. It is understood in these teams that these estimates are rough guesses used for general planning purposes and they usually revisit the estimates in a Backlog Refinement closer to actually working the item.

          • Sprint Planning: It isn’t common practice anymore to estimate right at sprint planning, but it still happens sometimes. Usually, this happens with stories that emerge right before the sprint (maybe a gap discovered in the last Sprint Review). This estimate is usually done at this time in order to weigh the cost/value benefit before deciding to bring it into the sprint.

          share

            up vote
            14
            down vote

            accepted

            up vote
            14
            down vote

            accepted

            The only certain answer is: sometime before the story is added into the sprint. After that the story point estimate doesn’t add much value.

            Common times that Scrum teams estimate stories:

            • Backlog Refinement: In backlog refinement the team looks one or two sprints out to see what is coming up and prepares these stories to be brought into a sprint. Estimation is a common thing to happen here because the act of trying to estimate the story often brings out details about the story.

            • Release Planning: This is a planning that takes a high-level look at the next few months and I’ve worked with many teams that take a first-guess estimate at all stories in the release planning. It is understood in these teams that these estimates are rough guesses used for general planning purposes and they usually revisit the estimates in a Backlog Refinement closer to actually working the item.

            • Sprint Planning: It isn’t common practice anymore to estimate right at sprint planning, but it still happens sometimes. Usually, this happens with stories that emerge right before the sprint (maybe a gap discovered in the last Sprint Review). This estimate is usually done at this time in order to weigh the cost/value benefit before deciding to bring it into the sprint.

            share

            The only certain answer is: sometime before the story is added into the sprint. After that the story point estimate doesn’t add much value.

            Common times that Scrum teams estimate stories:

            • Backlog Refinement: In backlog refinement the team looks one or two sprints out to see what is coming up and prepares these stories to be brought into a sprint. Estimation is a common thing to happen here because the act of trying to estimate the story often brings out details about the story.

            • Release Planning: This is a planning that takes a high-level look at the next few months and I’ve worked with many teams that take a first-guess estimate at all stories in the release planning. It is understood in these teams that these estimates are rough guesses used for general planning purposes and they usually revisit the estimates in a Backlog Refinement closer to actually working the item.

            • Sprint Planning: It isn’t common practice anymore to estimate right at sprint planning, but it still happens sometimes. Usually, this happens with stories that emerge right before the sprint (maybe a gap discovered in the last Sprint Review). This estimate is usually done at this time in order to weigh the cost/value benefit before deciding to bring it into the sprint.

            share

            share

            share

            edited Nov 30 at 4:00

            answered Nov 29 at 8:49

            Daniel

            7,4052723

            7,4052723

                up vote
                4
                down vote

                A story point number is the outcome of an estimation of a user story, so story points are assigned when the team estimates the stories.

                The latest point in time where estimation can/should be done is when a story is being considered for inclusion in the current or upcoming sprint. This is normally during the planning session.

                A more common point to do the estimation is during a backlog refinement session once the team feels that the story is clear enough and small enough that they can start working on it and complete the story within one sprint.

                For long-term planning, it can be useful to already assign a tentative estimation to stories and/or epics that need further refinement. Even such a tentative estimation should come from the team.

                share|improve this answer

                  up vote
                  4
                  down vote

                  A story point number is the outcome of an estimation of a user story, so story points are assigned when the team estimates the stories.

                  The latest point in time where estimation can/should be done is when a story is being considered for inclusion in the current or upcoming sprint. This is normally during the planning session.

                  A more common point to do the estimation is during a backlog refinement session once the team feels that the story is clear enough and small enough that they can start working on it and complete the story within one sprint.

                  For long-term planning, it can be useful to already assign a tentative estimation to stories and/or epics that need further refinement. Even such a tentative estimation should come from the team.

                  share|improve this answer

                    up vote
                    4
                    down vote

                    up vote
                    4
                    down vote

                    A story point number is the outcome of an estimation of a user story, so story points are assigned when the team estimates the stories.

                    The latest point in time where estimation can/should be done is when a story is being considered for inclusion in the current or upcoming sprint. This is normally during the planning session.

                    A more common point to do the estimation is during a backlog refinement session once the team feels that the story is clear enough and small enough that they can start working on it and complete the story within one sprint.

                    For long-term planning, it can be useful to already assign a tentative estimation to stories and/or epics that need further refinement. Even such a tentative estimation should come from the team.

                    share|improve this answer

                    A story point number is the outcome of an estimation of a user story, so story points are assigned when the team estimates the stories.

                    The latest point in time where estimation can/should be done is when a story is being considered for inclusion in the current or upcoming sprint. This is normally during the planning session.

                    A more common point to do the estimation is during a backlog refinement session once the team feels that the story is clear enough and small enough that they can start working on it and complete the story within one sprint.

                    For long-term planning, it can be useful to already assign a tentative estimation to stories and/or epics that need further refinement. Even such a tentative estimation should come from the team.

                    share|improve this answer

                    share|improve this answer

                    share|improve this answer

                    answered Nov 29 at 8:50

                    Bart van Ingen Schenau

                    87569

                    87569

                        up vote
                        4
                        down vote

                        User Stories aren’t part of Scrum

                        User Stories are an Extreme Programming (XP) practice. (see this question)

                        However, every Scrum team I’ve worked with so far has used Extreme Programming practices alongside scrum.

                        This blog on scrum.org has a pretty good explanation:

                        Scrum does not mandate the usage of Planning Poker and Story Points.
                        That is right. Planning Poker and Story points are actually not part
                        of Scrum. This is the common misconception people have about Scrum
                        that I have found in the community. Scrum Team is free to choose how
                        they want to estimate. In fact, Scrum team is allowed to estimate in
                        hours if they wish. Scrum Team who is practicing XP will do Planning
                        Poker with Story Points every Sprint Planning.
                        Many Scrum Team found
                        this Planning Poker practice with Story Points is helpful.

                        While the blog seems to imply that XP wants you to play Planning Poker each Sprint Planning, the XP rules don’t talk about Planning Poker at all. They do describe making a time estimate at the moment a User Story is written.

                        There are no strict rules. Feel free to chose what works best for your team. In my personal experience, it works best to assign story points when creating the backlog, and reviewing them at the start of each sprint.

                        share|improve this answer

                        • User stories/tasks/cards/tickets ARE part of Scrum. However the Story points != hours is not part of Scrum.
                          – slebetman
                          Nov 30 at 2:55

                        • Do you have a source on that? The Scrum Guide only talks about product backlog items. If you do have a source, please answer the question I linked, because the accepted answer there says User Stories are not part of scrum.
                          – ONOZ
                          Nov 30 at 12:02

                        • You can call it “items” if you don’t want to call it product backlog stories – but they’re still tasks broken down such that a developer can pick it up and work on it. Different names – same thing. The cards/tasks/items/stories may have different feature sets depending on how the team work but they’re a core part of Scrum. I’ve worked on teams where “tasks” must be in the form of “As a <stakeholder role> I want <feature description>”. I’ve worked on teams where “stories” are just bullet points of feature requirements etc.
                          – slebetman
                          Nov 30 at 12:27

                        • 1

                          @slebetman the term is “Product Backlog Item” and they’re not really the same thing; stories are a specific implementation of a PBI, but a PBI can look completely different. They also don’t need to contain tasks; many of mine just contain the description of a problem that we’re supposed to tackle.
                          – Erik
                          Nov 30 at 12:56

                        up vote
                        4
                        down vote

                        User Stories aren’t part of Scrum

                        User Stories are an Extreme Programming (XP) practice. (see this question)

                        However, every Scrum team I’ve worked with so far has used Extreme Programming practices alongside scrum.

                        This blog on scrum.org has a pretty good explanation:

                        Scrum does not mandate the usage of Planning Poker and Story Points.
                        That is right. Planning Poker and Story points are actually not part
                        of Scrum. This is the common misconception people have about Scrum
                        that I have found in the community. Scrum Team is free to choose how
                        they want to estimate. In fact, Scrum team is allowed to estimate in
                        hours if they wish. Scrum Team who is practicing XP will do Planning
                        Poker with Story Points every Sprint Planning.
                        Many Scrum Team found
                        this Planning Poker practice with Story Points is helpful.

                        While the blog seems to imply that XP wants you to play Planning Poker each Sprint Planning, the XP rules don’t talk about Planning Poker at all. They do describe making a time estimate at the moment a User Story is written.

                        There are no strict rules. Feel free to chose what works best for your team. In my personal experience, it works best to assign story points when creating the backlog, and reviewing them at the start of each sprint.

                        share|improve this answer

                        • User stories/tasks/cards/tickets ARE part of Scrum. However the Story points != hours is not part of Scrum.
                          – slebetman
                          Nov 30 at 2:55

                        • Do you have a source on that? The Scrum Guide only talks about product backlog items. If you do have a source, please answer the question I linked, because the accepted answer there says User Stories are not part of scrum.
                          – ONOZ
                          Nov 30 at 12:02

                        • You can call it “items” if you don’t want to call it product backlog stories – but they’re still tasks broken down such that a developer can pick it up and work on it. Different names – same thing. The cards/tasks/items/stories may have different feature sets depending on how the team work but they’re a core part of Scrum. I’ve worked on teams where “tasks” must be in the form of “As a <stakeholder role> I want <feature description>”. I’ve worked on teams where “stories” are just bullet points of feature requirements etc.
                          – slebetman
                          Nov 30 at 12:27

                        • 1

                          @slebetman the term is “Product Backlog Item” and they’re not really the same thing; stories are a specific implementation of a PBI, but a PBI can look completely different. They also don’t need to contain tasks; many of mine just contain the description of a problem that we’re supposed to tackle.
                          – Erik
                          Nov 30 at 12:56

                        up vote
                        4
                        down vote

                        up vote
                        4
                        down vote

                        User Stories aren’t part of Scrum

                        User Stories are an Extreme Programming (XP) practice. (see this question)

                        However, every Scrum team I’ve worked with so far has used Extreme Programming practices alongside scrum.

                        This blog on scrum.org has a pretty good explanation:

                        Scrum does not mandate the usage of Planning Poker and Story Points.
                        That is right. Planning Poker and Story points are actually not part
                        of Scrum. This is the common misconception people have about Scrum
                        that I have found in the community. Scrum Team is free to choose how
                        they want to estimate. In fact, Scrum team is allowed to estimate in
                        hours if they wish. Scrum Team who is practicing XP will do Planning
                        Poker with Story Points every Sprint Planning.
                        Many Scrum Team found
                        this Planning Poker practice with Story Points is helpful.

                        While the blog seems to imply that XP wants you to play Planning Poker each Sprint Planning, the XP rules don’t talk about Planning Poker at all. They do describe making a time estimate at the moment a User Story is written.

                        There are no strict rules. Feel free to chose what works best for your team. In my personal experience, it works best to assign story points when creating the backlog, and reviewing them at the start of each sprint.

                        share|improve this answer

                        User Stories aren’t part of Scrum

                        User Stories are an Extreme Programming (XP) practice. (see this question)

                        However, every Scrum team I’ve worked with so far has used Extreme Programming practices alongside scrum.

                        This blog on scrum.org has a pretty good explanation:

                        Scrum does not mandate the usage of Planning Poker and Story Points.
                        That is right. Planning Poker and Story points are actually not part
                        of Scrum. This is the common misconception people have about Scrum
                        that I have found in the community. Scrum Team is free to choose how
                        they want to estimate. In fact, Scrum team is allowed to estimate in
                        hours if they wish. Scrum Team who is practicing XP will do Planning
                        Poker with Story Points every Sprint Planning.
                        Many Scrum Team found
                        this Planning Poker practice with Story Points is helpful.

                        While the blog seems to imply that XP wants you to play Planning Poker each Sprint Planning, the XP rules don’t talk about Planning Poker at all. They do describe making a time estimate at the moment a User Story is written.

                        There are no strict rules. Feel free to chose what works best for your team. In my personal experience, it works best to assign story points when creating the backlog, and reviewing them at the start of each sprint.

                        share|improve this answer

                        share|improve this answer

                        share|improve this answer

                        answered Nov 29 at 14:03

                        ONOZ

                        15815

                        15815

                        • User stories/tasks/cards/tickets ARE part of Scrum. However the Story points != hours is not part of Scrum.
                          – slebetman
                          Nov 30 at 2:55

                        • Do you have a source on that? The Scrum Guide only talks about product backlog items. If you do have a source, please answer the question I linked, because the accepted answer there says User Stories are not part of scrum.
                          – ONOZ
                          Nov 30 at 12:02

                        • You can call it “items” if you don’t want to call it product backlog stories – but they’re still tasks broken down such that a developer can pick it up and work on it. Different names – same thing. The cards/tasks/items/stories may have different feature sets depending on how the team work but they’re a core part of Scrum. I’ve worked on teams where “tasks” must be in the form of “As a <stakeholder role> I want <feature description>”. I’ve worked on teams where “stories” are just bullet points of feature requirements etc.
                          – slebetman
                          Nov 30 at 12:27

                        • 1

                          @slebetman the term is “Product Backlog Item” and they’re not really the same thing; stories are a specific implementation of a PBI, but a PBI can look completely different. They also don’t need to contain tasks; many of mine just contain the description of a problem that we’re supposed to tackle.
                          – Erik
                          Nov 30 at 12:56

                        • User stories/tasks/cards/tickets ARE part of Scrum. However the Story points != hours is not part of Scrum.
                          – slebetman
                          Nov 30 at 2:55

                        • Do you have a source on that? The Scrum Guide only talks about product backlog items. If you do have a source, please answer the question I linked, because the accepted answer there says User Stories are not part of scrum.
                          – ONOZ
                          Nov 30 at 12:02

                        • You can call it “items” if you don’t want to call it product backlog stories – but they’re still tasks broken down such that a developer can pick it up and work on it. Different names – same thing. The cards/tasks/items/stories may have different feature sets depending on how the team work but they’re a core part of Scrum. I’ve worked on teams where “tasks” must be in the form of “As a <stakeholder role> I want <feature description>”. I’ve worked on teams where “stories” are just bullet points of feature requirements etc.
                          – slebetman
                          Nov 30 at 12:27

                        • 1

                          @slebetman the term is “Product Backlog Item” and they’re not really the same thing; stories are a specific implementation of a PBI, but a PBI can look completely different. They also don’t need to contain tasks; many of mine just contain the description of a problem that we’re supposed to tackle.
                          – Erik
                          Nov 30 at 12:56

                        User stories/tasks/cards/tickets ARE part of Scrum. However the Story points != hours is not part of Scrum.
                        – slebetman
                        Nov 30 at 2:55

                        User stories/tasks/cards/tickets ARE part of Scrum. However the Story points != hours is not part of Scrum.
                        – slebetman
                        Nov 30 at 2:55

                        Do you have a source on that? The Scrum Guide only talks about product backlog items. If you do have a source, please answer the question I linked, because the accepted answer there says User Stories are not part of scrum.
                        – ONOZ
                        Nov 30 at 12:02

                        Do you have a source on that? The Scrum Guide only talks about product backlog items. If you do have a source, please answer the question I linked, because the accepted answer there says User Stories are not part of scrum.
                        – ONOZ
                        Nov 30 at 12:02

                        You can call it “items” if you don’t want to call it product backlog stories – but they’re still tasks broken down such that a developer can pick it up and work on it. Different names – same thing. The cards/tasks/items/stories may have different feature sets depending on how the team work but they’re a core part of Scrum. I’ve worked on teams where “tasks” must be in the form of “As a <stakeholder role> I want <feature description>”. I’ve worked on teams where “stories” are just bullet points of feature requirements etc.
                        – slebetman
                        Nov 30 at 12:27

                        You can call it “items” if you don’t want to call it product backlog stories – but they’re still tasks broken down such that a developer can pick it up and work on it. Different names – same thing. The cards/tasks/items/stories may have different feature sets depending on how the team work but they’re a core part of Scrum. I’ve worked on teams where “tasks” must be in the form of “As a <stakeholder role> I want <feature description>”. I’ve worked on teams where “stories” are just bullet points of feature requirements etc.
                        – slebetman
                        Nov 30 at 12:27

                        1

                        1

                        @slebetman the term is “Product Backlog Item” and they’re not really the same thing; stories are a specific implementation of a PBI, but a PBI can look completely different. They also don’t need to contain tasks; many of mine just contain the description of a problem that we’re supposed to tackle.
                        – Erik
                        Nov 30 at 12:56

                        @slebetman the term is “Product Backlog Item” and they’re not really the same thing; stories are a specific implementation of a PBI, but a PBI can look completely different. They also don’t need to contain tasks; many of mine just contain the description of a problem that we’re supposed to tackle.
                        – Erik
                        Nov 30 at 12:56

                        up vote
                        1
                        down vote

                        This answer is structured in the following way:

                        1. Example of a cycle for a two week sprint.
                        2. Why story points?
                        3. When to assign story points to the user-stories?

                        The following image, taken from How to Kill the Scrum Monster: Quick Start to Agile Scrum Methodology and the Scrum Master Role shows an example of a meeting cycle for a two-week Sprint (Of course, all those meetings are not set in stone and can be adjusted based on need):

                        scrum

                        Planning (mandatory) meeting: The team plans what user stories (backlogs) it will execute during the Sprint and breaks them into tasks. The team commits to completing those during the Sprint according to the Definition of Done (DoD).

                        Backlog grooming (optional) during execution of the Sprint N: The PO will introduce new backlogs if required and this meeting wil be an opportunity for the team to ask questions about backlogs for the next Sprint (N+1).

                        Sprint review (mandatory): The ScMa and the team present to the PO all the backlogs that were committed this Sprint, and status according to the DoD.

                        Retrospective (mandatory) team meeting: Team members discuss what went wrong, what went well, and if anything should be changed to improve team performance—also used as a meeting to release some steam. (Can be executed every second Sprint in case of short Sprints.)

                        Scrum meeting or Stand-up (mandatory): short daily meeting where team developers answer three questions: What was done since the last meeting? What are the blocks? What will I be doing next?

                        Now, Story points are estimates of effort assigned to user stories based on the amount of work, complexity, uncertainty, and risk.

                        Eventually the team will learn how many story points it can take during a Sprint and it will be considered as team velocity. To measure the velocity, average of the last three Sprints can be used.

                        From my experience, the story points were always given in the first day of the sprint, the planning meeting. Of course sometimes developers realize the story would actually be worth more / less story points (that is mentioned in the retrospective meeting) but generally speaking, because that’s a group decision and these conversations increase the team’s knowledge about each story, which will help to make the estimates more accurate.

                        share|improve this answer

                          up vote
                          1
                          down vote

                          This answer is structured in the following way:

                          1. Example of a cycle for a two week sprint.
                          2. Why story points?
                          3. When to assign story points to the user-stories?

                          The following image, taken from How to Kill the Scrum Monster: Quick Start to Agile Scrum Methodology and the Scrum Master Role shows an example of a meeting cycle for a two-week Sprint (Of course, all those meetings are not set in stone and can be adjusted based on need):

                          scrum

                          Planning (mandatory) meeting: The team plans what user stories (backlogs) it will execute during the Sprint and breaks them into tasks. The team commits to completing those during the Sprint according to the Definition of Done (DoD).

                          Backlog grooming (optional) during execution of the Sprint N: The PO will introduce new backlogs if required and this meeting wil be an opportunity for the team to ask questions about backlogs for the next Sprint (N+1).

                          Sprint review (mandatory): The ScMa and the team present to the PO all the backlogs that were committed this Sprint, and status according to the DoD.

                          Retrospective (mandatory) team meeting: Team members discuss what went wrong, what went well, and if anything should be changed to improve team performance—also used as a meeting to release some steam. (Can be executed every second Sprint in case of short Sprints.)

                          Scrum meeting or Stand-up (mandatory): short daily meeting where team developers answer three questions: What was done since the last meeting? What are the blocks? What will I be doing next?

                          Now, Story points are estimates of effort assigned to user stories based on the amount of work, complexity, uncertainty, and risk.

                          Eventually the team will learn how many story points it can take during a Sprint and it will be considered as team velocity. To measure the velocity, average of the last three Sprints can be used.

                          From my experience, the story points were always given in the first day of the sprint, the planning meeting. Of course sometimes developers realize the story would actually be worth more / less story points (that is mentioned in the retrospective meeting) but generally speaking, because that’s a group decision and these conversations increase the team’s knowledge about each story, which will help to make the estimates more accurate.

                          share|improve this answer

                            up vote
                            1
                            down vote

                            up vote
                            1
                            down vote

                            This answer is structured in the following way:

                            1. Example of a cycle for a two week sprint.
                            2. Why story points?
                            3. When to assign story points to the user-stories?

                            The following image, taken from How to Kill the Scrum Monster: Quick Start to Agile Scrum Methodology and the Scrum Master Role shows an example of a meeting cycle for a two-week Sprint (Of course, all those meetings are not set in stone and can be adjusted based on need):

                            scrum

                            Planning (mandatory) meeting: The team plans what user stories (backlogs) it will execute during the Sprint and breaks them into tasks. The team commits to completing those during the Sprint according to the Definition of Done (DoD).

                            Backlog grooming (optional) during execution of the Sprint N: The PO will introduce new backlogs if required and this meeting wil be an opportunity for the team to ask questions about backlogs for the next Sprint (N+1).

                            Sprint review (mandatory): The ScMa and the team present to the PO all the backlogs that were committed this Sprint, and status according to the DoD.

                            Retrospective (mandatory) team meeting: Team members discuss what went wrong, what went well, and if anything should be changed to improve team performance—also used as a meeting to release some steam. (Can be executed every second Sprint in case of short Sprints.)

                            Scrum meeting or Stand-up (mandatory): short daily meeting where team developers answer three questions: What was done since the last meeting? What are the blocks? What will I be doing next?

                            Now, Story points are estimates of effort assigned to user stories based on the amount of work, complexity, uncertainty, and risk.

                            Eventually the team will learn how many story points it can take during a Sprint and it will be considered as team velocity. To measure the velocity, average of the last three Sprints can be used.

                            From my experience, the story points were always given in the first day of the sprint, the planning meeting. Of course sometimes developers realize the story would actually be worth more / less story points (that is mentioned in the retrospective meeting) but generally speaking, because that’s a group decision and these conversations increase the team’s knowledge about each story, which will help to make the estimates more accurate.

                            share|improve this answer

                            This answer is structured in the following way:

                            1. Example of a cycle for a two week sprint.
                            2. Why story points?
                            3. When to assign story points to the user-stories?

                            The following image, taken from How to Kill the Scrum Monster: Quick Start to Agile Scrum Methodology and the Scrum Master Role shows an example of a meeting cycle for a two-week Sprint (Of course, all those meetings are not set in stone and can be adjusted based on need):

                            scrum

                            Planning (mandatory) meeting: The team plans what user stories (backlogs) it will execute during the Sprint and breaks them into tasks. The team commits to completing those during the Sprint according to the Definition of Done (DoD).

                            Backlog grooming (optional) during execution of the Sprint N: The PO will introduce new backlogs if required and this meeting wil be an opportunity for the team to ask questions about backlogs for the next Sprint (N+1).

                            Sprint review (mandatory): The ScMa and the team present to the PO all the backlogs that were committed this Sprint, and status according to the DoD.

                            Retrospective (mandatory) team meeting: Team members discuss what went wrong, what went well, and if anything should be changed to improve team performance—also used as a meeting to release some steam. (Can be executed every second Sprint in case of short Sprints.)

                            Scrum meeting or Stand-up (mandatory): short daily meeting where team developers answer three questions: What was done since the last meeting? What are the blocks? What will I be doing next?

                            Now, Story points are estimates of effort assigned to user stories based on the amount of work, complexity, uncertainty, and risk.

                            Eventually the team will learn how many story points it can take during a Sprint and it will be considered as team velocity. To measure the velocity, average of the last three Sprints can be used.

                            From my experience, the story points were always given in the first day of the sprint, the planning meeting. Of course sometimes developers realize the story would actually be worth more / less story points (that is mentioned in the retrospective meeting) but generally speaking, because that’s a group decision and these conversations increase the team’s knowledge about each story, which will help to make the estimates more accurate.

                            share|improve this answer

                            share|improve this answer

                            share|improve this answer

                            answered Nov 29 at 9:17

                            tiagoperes

                            33318

                            33318

                                draft saved
                                draft discarded

                                Thanks for contributing an answer to Project Management Stack Exchange!

                                • Please be sure to answer the question. Provide details and share your research!

                                But avoid

                                • Asking for help, clarification, or responding to other answers.
                                • Making statements based on opinion; back them up with references or personal experience.

                                To learn more, see our tips on writing great answers.

                                Some of your past answers have not been well-received, and you’re in danger of being blocked from answering.

                                Please pay close attention to the following guidance:

                                • Please be sure to answer the question. Provide details and share your research!

                                But avoid

                                • Asking for help, clarification, or responding to other answers.
                                • Making statements based on opinion; back them up with references or personal experience.

                                To learn more, see our tips on writing great answers.

                                draft saved

                                draft discarded

                                StackExchange.ready(
                                function () {
                                StackExchange.openid.initPostLogin(‘.new-post-login’, ‘https%3a%2f%2fpm.stackexchange.com%2fquestions%2f25346%2fwhen-does-a-scrum-team-assign-story-points-to-the-stories-in-the-scrum-methodolo%23new-answer’, ‘question_page’);
                                }
                                );

                                Post as a guest

                                Required, but never shown

                                Required, but never shown

                                Required, but never shown

                                Required, but never shown

                                Required, but never shown

                                Required, but never shown

                                Required, but never shown

                                Required, but never shown

                                Required, but never shown

                                Related Post

                                Leave a Reply

                                Your email address will not be published. Required fields are marked *