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?

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.

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):

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.