Should we story point our tasks?

What are story points?

Before we consider whether or not we should put story points on tasks, we need to learn what story points are and why we use them.

Story points are a measure of how laborious a piece of work will be to complete. Labor can come in multiple dimensions.

You could have a relatively simple new feature you want to add which is well understood and unlikely to generate surprises but will simply take a long time to implement because there's a large amount of code to write. That's laborious.

On the other hand, you might have a feature which is likely to be small in terms of the number of lines of code but requires someone to relearn a part of the codebase which is rarely used. Time will be spent understanding the existing code and therefore the laboriousness is increased.

There's also the disagreement dimension. If we know we need a feature and the development team knows multiple ways to build it, we might need discussion time to work through the different solutions and agree on the best one. This is also laborious.

Tasks vs Stories

Labor comes in many variants. In scrum (at least as recorded in JIRA), we have stories, tasks, bugs and a bunch of other variants of "piece of work".

In my mind, a story is a piece of work which will be visible to end users. "Add Chat Widget" is a story because the end user will see a chat widget when it's complete. On the other hand, "Refactor job framework" is a task because the job framework is internal to our application. If the user notices that you've refactored the job framework it's probably because you messed up and they're experiencing a bug.

Stories can be easily written in the User Story format.

As a heavy user of the application,
I want to have access to a chat widget,
So I can send emojis to my many online friends.

While you can usually shoehorn a task into this format, when was the last time you used an application and thought "Man I wish the development team behind this application would refactor their job framework base so I could…"? Probably never, right? That makes it a task in my mind.

So they're variants of the same thing?

Both stories and tasks are variants of "piece of work" and both involve labor so shouldn't they both have story points?

Maybe not...

If the user never notices that we refactored the job framework, why did we bother doing it? The idea is that it makes future development less costly.

But future development of what? Stories of course! Wouldn't you be worried if a development team wanted to refactor component A so they could ease refactoring of module B, subsequently speeding up the planned refactor of other component C? Eventually, we have to deliver value that the user can see.

But we have to do tasks to make the stories possible. In this way, they can be seen as a tax on the delivery of value. The labor of a task is accounted for in the story points of the stories because the tasks enable the stories.

There are two models

The non-story-pointed-tasks makes the most sense to me if you have a tight coupling between the value of your stories and the tax on your tasks. I feel like if you use this model you should probably have tasks divided up into epics. If the chat widget can't be added without refactoring the job framework so we can handle a higher throughput of messages, this should be indicated in the backlog somehow, likely by making the refactoring a subtask of a "Add chat widget" story or epic.

On the other hand, if you have a much more loose coupling between tasks and value, sizing tasks with story points might be the way to go. If you're refactoring the job framework because you feel strongly that it will bring improvements later in the year but you can't tie it into a specific story or epic right now then perhaps it should have story points on it.