Skip to main content

Which stories should be assigned Story Points and which shouldn't.

Last post 09:36 pm July 23, 2018 by Timothy Baffa
7 replies
03:25 am July 14, 2018

Hello everyone,

I couldn't find a thread which discussed this question so I decided to create separate thread.

We are practicing Scrum for last one year.

Somewhere I heard/read that Story Points can be assigned to only stories which talks about implementing features/functionality. So considering this SPIKES are not assigned Story Points.

My question is here - 

If team decides to build an utility/tool which helps automate/expedite development efforts, should this story of building tool/utility be assigned Story Points?


Thanks in advance

09:44 pm July 16, 2018

Story Points aren't a required part of Scrum. However, it is a practice that many teams use in order to provide the attribute of an estimate that Product Backlog Items have. It's not the only way to estimate a PBI, and the Scrum framework doesn't mandate any particular estimation techniques.

Spikes are also not an element of Scrum, but it is another practice that some teams choose to use in order to denote a specific chunk of work that needs to be done to better understand one or more Product Backlog Items. This work does take up time in the Sprint, and tracking it's progress does make sense to me, but there's no definition of what is or isn't a Spike in the Scrum framework.

How does your team use the Story Points assigned to work? What would happen if you assigned Story Points to this work? What if you didn't? How would this impact your ability to carry out Sprint Planning, Sprint Reviews, and Sprint Retrospectives?


01:01 am July 17, 2018

The view that non-functional requirements cannot have story points may be to confuse story points with story value.

Relative to story value, story points is the cost of finishing a user story. 

This type of work is not too exciting for the customers, but still valuable because we are reducing risk and increasing productivity. 



01:44 am July 17, 2018

>How does your team use the Story Points assigned to work? What would happen if you assigned

>Story Points to this work? What if you didn't? How would this impact your ability to carry out

>Sprint Planning, Sprint Reviews, and Sprint Retrospectives?

Those questions are really insightful. That got me thinking more about SP usage. My answers below

1. My team use Story Points to track team velocity and release burn-down.

2. General direction we follow while applying Story Points is - apply Story Points to stories which are customer facing or it is some feature/functionality (I know I'm being very vague here!). So defects do not have SP similar to Spikes which as you rightly mentioned are for doing background work on a PBI before we start working on it. 

3. We start sprint planning taking SP velocity as base, then we end up planning as per team's capacity in hours for that sprint.


Should I assign SP to all the stories/PBIs except defects in order to better predict team velocity which will help in better sprint planning? Any guidelines.


05:12 am July 17, 2018

If team decides to build an utility/tool which helps automate/expedite development efforts, should this story of building tool/utility be assigned Story Points?

It should be possible at all times to forecast the amount of work which is thought to remain for a Product.

If the building of a tool or utility is a necessary part of that body of work, then it ought to be included in the measure and estimated accordingly.

12:16 pm July 17, 2018

Sharad, what you are describing here doesn't sound like a spike.  It's more a continuous improvement idea that will help the team in the longer term.  Pointing seems ok for this.  

A word of caution on spikes.  Spikes are generally used for investigative activity.  However, I do not advocate pointing spikes.  Instead, a time box allows us to account for the effort required but also reflect the impact on velocity.  

Why?  Spikes are often used to compensate for ineffective backlog refinement.  Time that should be absorbed by the the team during the sprint to routinely refine the backlog is deferred and stuck in a spike.  Spikes are considered during sprint planning and as a result, less will be added to the sprint backlog.  

Spikes have their place, but not as a sticking plaster for underlying bad practice.

01:33 am July 23, 2018

The way we do it, user stories usually have associated tasks. For example:

User story: "As a registered user, I want to log into the site using my username and password, so that I can access content for members only."


Task 1 - Create a login form

Task 2 - Create database tables

Task 3 - Create server script to handle the login request




Task X - etc...

Each of these tasks will have points assigned to them by the development team. Some teams will use relative estimation for the stories and time estimation for the tasks. However, I prefer to do things differently to avoid having two different metrics. The way we do it, the story points will simply be the total of all the points of the tasks associated with that user story. The tasks are estimated during backlog refinement meetings. This is what works best for my team and feel free to figure out what works best with yours.

There is no defined way on how to make these estimates in the Scrum guide. This means that you can freely inspect and adapt to what works best for your team. 




09:36 pm July 23, 2018


I must admit that while unusual, I do not object to your estimation practice as laid out.   You relatively estimate at the task level, and you roll up those task estimates to come up with a cumulative story point estimate for the item.   You do not mix relative and time-based estimates.   And it seems to work for your team.

I do have a question though.   There must be times where the team has not considered all possible tasks for an item in Sprint Planning.   When additional tasks are identified, how does the team manage that within the sprint?


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.