Should we assign points to a chore? 

My short answer is “yes”.  I’ll explain why below.

First, what is a chore? Many teams make a distinction between stories and chores in their backlog.  A story – specifically a user story – is something that the users value in the software.  A chore is something that must be done, but the user doesn’t independently value. 

A couple of tests to determine if some unit of work is a story or a chore are as follows: 

1.) Ask about value:  “Would the customer pay for this?”  For example:  If I go to the customer / user and ask: “Would you pay for the ability for the user to sort their search results by any field?”  The customer is likely to say, yes, we want that feature, we see value in it, and we are willing to pay for it.   This indicates that this is a good candidate for a story.  Now, if I ask the customer: “Would you pay for us to set up a continuous integration server, and work on the build script?”  The customer is likely to say, “Huh?”…  This may indicate this unit of work is a good candidate for a chore.

2.) Is it easy to write the story in the common format of “As as <type of user>, I want <some feature>, so that I can accomplish <some goal>”?  If it’s easy to describe the work using this format, than it’s probably a good user story.  If it’s difficult to fit the work into this format, there’s a good chance it’s a chore. 

So, we now have two types of work: Stories (user stories) and Chores.  What’s the difference?  Well, for many teams they only assign story points to stories and not chores.  The thinking goes that if we assign points only to stories, that we can equate the points in the backlog to value the user will receive.

This goes to the definition of velocity.  If we define velocity as the number of “User Story” points – and only user story points – completed in a iteration – then we can’t assign story points to chores because they should not be included in the velocity.  If, however, we define velocity as the number of story points (and we don’t care what type of story) completed per iteration – then it’s best to assign points to these stories.

I generally find this argument unconvincing for a two reasons:  First, no matter how we categorize a unit of work, it’s likely that it needs to be done for the product to be completed and released – so we may as well include it in our effort estimates.  Second, for practical reasons, I look at all work as scope for the release and want to include that work in our total product backlog. (Note: This assumes that only work related to delivering the product goes on the product backlog.  Other work the team members must do that is not directly related to delivering the product is not included in the product backlog.)  This makes the burn up chart more useful by showing any changes in the scope in the top line of the burn up chart.   

If we don’t assign points to chores, we could see our reported velocity to do down, but we are given no insight into why it went down.  Was it due to the team taking on a lot of chores, or could it be due to slowing progress.  

We also lose any insight on the total work remaining in the project.  If we only show the work that we consider of direct value to the user, we would not see an increase in the total scope if a larger number of chores were added.  We would not see the additional work on the top line of the burn up chart, but only see the velocity go down.

If we assign points to all stories, regardless of the type – we will always see a bump in the total scope when work is added, as show below:

Now, we may still decide to not do the chore in a particular iteration and take on user focused stories instead.  But this is a prioritization question, and not an velocity accounting question.  On balance, I think that you get more information by assigning points to all types of stories – including chores.