Should tasks be pointed?

Joseph,

There may be work that the team does in a sprint that does not produce business value (maintenance tasks, run-time tasks, removing technical debt, etc).The team should always consider such task work when evaluating the Sprint Offer to determine what they can forecast for the upcoming sprint.

I agree with you that it is wasteful to estimate such non-sprint tasks; however, it may be a good practice to make such work visible (physical board, electronic board) so that everyone is aware of the work being performed.

> The issue is, if the team has committed to a certain amount of work, in story
> points, where does the work that is needed for the task get accounted for?

If the team is committing to a certain amount of work in story points, the issue is that they have applied Scrum poorly. A team should commit to a Sprint Goal instead. That's what a Sprint is for. Story points are just a means for the team to estimate how much work they can take on, so they can frame an achievable goal accordingly.

If a team have non-product related work to do during a Sprint, they *may* wish to size it in points and revise their budget for the Sprint by a corresponding amount. When that non-product work is done, the team *may* then choose to account for it by including it in velocity or throughput metrics, on the grounds that they were not idle. It could not, however, be reflected in a product burndown as it has no bearing on remaining product scope.

When a team is applying refactoring, improvement, or doing some other tasks -- they do this because of something... it usually goes along with an increment agreed as a Sprint Goal.
In other words, it's almost always an additional task required toward the Sprint Goal (and is relevant to one of the story/feature/epic).
For the timesheet accuracy purpose - we create a general scrum activity task every sprint. So, all the activity required to run Scrum goes under that category.

Tasks eat up time without producing value visible to customers. The extra effort will cut into team performance and will be visible as a decrease in team velocity.

That's how I communicate it to the team and PO.

We collect the number of SP as well as the number of bugs, tasks, changes to make the work outside Stories visible.

Refactoring, in my view, is a different matter. If it can be done immediately and with little risk, it should be done as soon as it's identified. If it's a bigger affair, discuss with the Scrum Team.

If the task relates directly to the system you're developing then define the system as a user in a user story. Then apply the same principles as normal. The system on itself delivers value, not only it's functions to the business.