A project I’m aware of recently started discussing in their retrospectives that they wanted to start assigning points to tech tasks. I’m a big believer in allowing a team to exercise control over its own process — so in my mind the right answer is to let the team make the call. I do have some thoughts on the matter however.
Tech Tasks Aren’t The Goal
Velocity is a measure of a team’s ability to do useful work. At the end of an iteration the team can look back and add up the points for all the stories that it worked on. If a team somehow ended up spending all its time on technical tasks (which is a valid thing to do from time to time), it’s velocity would still reflect the effort put in to those technical tasks. That’s a good thing, right?
I’m not saying that you don’t have to do tech tasks — it’s just that they are not the goal of the project. You want to measure the steady advance of new features.
So what do you do when the team spends an entire iteration on tech tasks? You take a zero. The conversation with the Product Owner might go: “This is the iteration where we agreed it would make the most time to refactor the fizzbuzz package. If we end up squeezing in a story, we’ll have some velocity, otherwise we’re probably going to show zero velocity.”
Liz has some great things to say about what she calls Stakeholder Tasks. I’d apply this thought to requirements that come not from our understanding of what the user would want, but what other stakeholders may require us to do.
Points Don’t Measure Business Value
I’ve heard people take this concept few steps farther and say that points are a measure of business value. I think this is stretching the analogy a bit too far — the 3 point story on paging search results that took half the iteration didn’t necessarily have three times the business value of the one point UX story that doubled conversion. Points are a measure of story size (effort) not value.