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.”
Stakeholder Tasks
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.
Software Development 
I say assign points to the tech stories – but don’t count it as value delivered.
Points represent an estimate of difficulty, and are used as a limiting factor, both on the work itself (so you know if you’re taking longer than you thought), and on iteration planning (so you don’t commit to too much work). If you’re using points, you should use them for everything – including tech tasks.
So if you’ve got a velocity of, say, 10 points per week, and you want to spend a week technical tasks, then you prepare 10 points worth of estimates. If you deliver that, your velocity – for ongoing planning purposes – is still 10. Of course, as far as project value goes, you’ve delivered no value. But value isn’t effort, and points track effort.
One point: refactoring is the explicit example of a task that shouldn’t be separated out. You want to keep the code clean always – if you’re leaving it in a state to be refactored, then your earlier work isn’t “done done”. Better examples would include replacing a backend library, upgrading the database, putting in a better performing algorithm – all things that may have actual value.
Keeping code clean is one kind of refactoring, and you and I agree it comes as part of the story. However there are refactoring tasks that end up being scheduled… Sometimes you need to make a design change but don’t have a story to hang it on.
Something must be driving the need, though – you should be able to find a story, or a set of stories, that are the reason for doing the work, even if the reason is nothing more than to reduce the size of future estimates
Oh – another reason to estimate tech tasks (any task, including refactoring) in points is that you _can_ assign a value to them, of sorts. That value is “this task will reduce the estimate of _these_ tasks by this much”. This in turn helps decide if it’s time to do the task – it’s time to do it when the “value” it delivers (the sum of the reduction of effort of upcoming stories) exceeds the cost.
I’ve always liked the concept of finding an ROI as you suggest on tech tasks. I’ve sometimes had conversations with product owners along the lines of “right now we see the work as a 2 and a 3. we’re hoping for xyz value.” Yes, sizing the work helped in these conversations. I still don’t like this counting towards velocity however.
It’s a matter of incentives. There shouldn’t be a velocity “incentive” for doing tech tasks – they’re just part of the work.
I have always treated Tech Tasks and Tech Debt differently. Some tasks just have to be done like setup of environments, 3rd parties etc… and they get points.
I tend to not claim tech debt as points as it creates a false notion of productivity. Debt should show as drag on the team because of codebase not being attended to on time.
In a way, you need to differentiate between Value demand and Failure demand. Check http://en.wikipedia.org/wiki/Lean_services#Value_Demand_and_Failure_Demand
Nice, thanks Anand. I like the distinction.