What should have Story Points?

A fellow ScrumMaster posted the following question on a board on a popular career related site.

I had a discussion with my interviewer about if there is some technical related work( indirectly related to the story in sprint) should have a story point value or not! My thought is 'anything done in sprint should have a story point value.' Any thoughts?

I still believe the purpose of story points is to represent the Product Backlog. The items in the Product Backlog represent increments of Business Value to our customers. I believe that the points are a forecasting tool for the Scrum Team to use historical performance to estimate future expectations. If that is the case, and I am a Product Owner; wanting to give expectations to my customer, stakeholders, and organization, I will want to see decreases in velocity from Sprints were we worked on things other than Business Value that our customer approves of and requests from us.

I do not suggest Story Points for anything except for stories. If you track hours at the task level, then I suggest putting hours towards tasks unassociated with the Sprint goal "on the board" for these types of items. If you do not then you will deliver less of the Product Backlog in that Sprint.

My fear of robots, er... tools, pt 4

I have a fear of team communication being reduced as valuable interaction is now funneled into tool use.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 

I see this with common office tools like the phone and email. I see teams who are collocated call someone who is outside of their team rooms but located on the same floor as their team for a conversation that may last longer than a few minutes. I see teams email each other when they are collocated. That one is my personal button…

If a team is expected to keep record within a tool they may start to look to this tool as the method to communicate. I have seen team say "Why do it twice?" The tool is often not for them but, if they are judged by what it contains, they may start to use it as the only method of communication. CYA becomes the rule of thumb. I have seen test specialists and dev specialists who sit right next to each other speak to each other through the test case tracking software. Very frustrating…

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

My fear of robots, er... tools, pt 3

​I have a fear of managers using tools to judge their teams in the absence of interaction. 

I have seen managers request the feedback from tools to gather data to support the endeavors of the team. When pressure is applied for acceleration, increased efficiency, or more productivity, the team is punished with the data pulled from the tool without the valuable conversation that should go with it. ​

​Estimates are considered exactimates; precise commitments by the team. 

​The output of the tools are distributed around the organization without education on the new mindset of how we work.

​Trust broken...

My fear of robots, er... tools, pt 2

Teams may change behavior to support the shortcomings of a tool.

I have observed teams in the past that would forgo good behaviors because their tools did not support them. Of course there is the chance for a team to pick up bad behaviors because a tool reinforces it. 

A tool should exist to support the endeavor of the team while allowing their good practices to flourish. ​