When does a Scrum Team assign story points to the stories in the Scrum methodology?
Clash Royale CLAN TAG#URR8PPP
up vote
8
down vote
favorite
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
add a comment |
up vote
8
down vote
favorite
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
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
add a comment |
up vote
8
down vote
favorite
up vote
8
down vote
favorite
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
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
scrum agile user-stories story-points
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
add a comment |
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
add a comment |
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.
add a comment |
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.
add a comment |
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.
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
add a comment |
up vote
1
down vote
This answer is structured in the following way:
- Example of a cycle for a two week sprint.
- Why story points?
- 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):
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.
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
edited Nov 30 at 4:00
answered Nov 29 at 8:49
Daniel
7,4052723
7,4052723
add a comment |
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
answered Nov 29 at 8:50
Bart van Ingen Schenau
87569
87569
add a comment |
add a comment |
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.
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
add a comment |
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.
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
add a comment |
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.
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.
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
add a comment |
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
add a comment |
up vote
1
down vote
This answer is structured in the following way:
- Example of a cycle for a two week sprint.
- Why story points?
- 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):
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.
add a comment |
up vote
1
down vote
This answer is structured in the following way:
- Example of a cycle for a two week sprint.
- Why story points?
- 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):
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.
add a comment |
up vote
1
down vote
up vote
1
down vote
This answer is structured in the following way:
- Example of a cycle for a two week sprint.
- Why story points?
- 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):
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.
This answer is structured in the following way:
- Example of a cycle for a two week sprint.
- Why story points?
- 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):
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.
answered Nov 29 at 9:17
tiagoperes
33318
33318
add a comment |
add a comment |
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.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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