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

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?

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. 

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

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.

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.

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

Tasks:

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. 

Cheers,

Harley

Harley,

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?