Story points should be assigned independently to every task according to its estimation. Assigning should take place during sprint planning in an issue tracking tool that the scrum team uses.
What are story points you can find out here – but if you are searching for the assignment of story points then I assume that you know what it is.
Assigning story points independently
Every task has its own estimation, but not every backlog item.
You should only assign story points to tasks that will be really worked on. There are backlog items that hold high-level requirements or/and aggregate other items.
For example, You can have a user story that gives context about who is using the functionality and what is the purpose. However, it doesn’t say how the functionality will be implemented. You can aggregate tasks in a user story – then you can assign story points to those tasks and leave the user story without an estimate. Unless You really want the user story in a sprint then give it 0 story points – this way You can take the story to the sprint backlog and still have the work estimated once.
In the example above user story 1 aggregates tasks 1, 2, and 3. Only tasks are estimated here as they represent the work planned for the sprint. The user story is realized by tasks so it gets story points value of 0. In the grey circle on the top, we can see the sum of story points of tasks in “to do” status.
The estimation is a process of defining how big a task is in relation to its complexity, work labor, and uncertainty.
The way I encourage You to approach this subject is to take the estimation process holistically. Every team member should work on the estimation, and testing the functionality is included in the estimation.
I will cover the estimation process in depth in a different article.
Story points estimation on sprint planning
During backlog refinement, the developers can be eager to estimate – I strongly advise leaving the estimation for the planning event.
When the team refines backlog items they should focus on technical details and business logic. The estimation process is less precise. I was always afraid that developers would lose focus if every now and then they disrupt refinement for estimation. Besides if there is a day or two break in thinking about new features between the refinement and the planning then the concept of how to implement new functionality is already ordered in the developer’s heads. It is easier to look at work from a perspective and estimate.
When every task in the sprint backlog is assigned then You can easily check how many story points are planned for the sprint. Does it exceed the capacity for the sprint? If so before the sprint starts the scrum team should adjust the number.
As a scrum team, we do not measure how many story points a particular developer does in a sprint but everyone knows approximately what is his/her average velocity. It is a hint for everyone independently on the difficulty of the planned sprint. Every developer then has a basis for agreement on the number of story points a team takes for the sprint.
Issue tracking tool
How easily the story points are assigned to issues also depends on the tool you are using.
I use Jira and the assigning of story points and analyzing the sum of it for the team and per assignee is a child’s play.
When you hover over a task you want to assign story points to, a grey circle appears – just hover over and click on it. You will then be able to input the number of story points you wish to assign to task 4 or use the up and down arrows to choose a number.
After choosing the value accept it and you are done 🙂
The sum of story points is changed. You can always return and modify every story points value.
Assign story points to tasks that you will work on during planning.
Keep in mind the capacity.
In your issue tracking tool it should be stupid easy – just assign the numbers and start the sprint 🙂