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?

  • 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 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.

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.

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

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 will 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): a 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, the 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.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.