I want to expand on not pointing technical debt stories. As I finished the last blog post, I realized that I had made the presumption that teams should only assign story points to stories based on business value. Then I proceeded to basically lay out the argument for why a team should (or in some cases should not) pay down their technical debt, kind of skirting the entire question of what not assign points in the first place. A classic case of begging the question: We only point things that are valuable because they are things that are valuable. If you already have bought into that statement, you wouldn't be here asking the question of whether to point tech. debt or not.
So now I want to back the premise that a team should only point work that is of value to the business. One of the developers I support is a fan of both metaphors and the NBA, so I would like to present my argument in these terms: When you watch a basketball game rebounds, assists, steals, and turnovers are all very important to the teams. However, at the end of forty minutes, the one stat that matters is how many points each team scored. Just like having a lot of turnovers will hurt a team's chances to win, technical debt is going to drag down your development's ability to deliver new features. In the end, however, the business runs on the value of the features the team delivers.
I mentioned previously that a team may look to distinguish between technical debt points and business value and still somehow combine those to estimate output. I don't believe that this is really an apples-to-apples comparison, however. Some technical debt MUST be addressed and some subset MUST be addressed IMMEDIATELY (particularly if bugs and incidents fall into that technical debt bucket). For example, our organization recently moved its package management from a Nexus repository to Artifactory. Every development team had to change projects to point to Artifactory. No value was delivered to the customer, but this had to be done by a set deadline else project build pipelines would cease to work. We also have contractual obligations for SOC 2 and PCI compliance driven by hard deadlines. Managing API keys and updating network diagrams does not deliver value to our customers but must be done and must be done by particular dates. If that date is a couple years off the tradeoff with choosing to bring in business value may be relatively small. That cost increases, however, as the deadline approaches.
Another thing that makes estimations of technical debt unequal to estimating business value is that technical debt, in my opinion, is generally more difficult to accurately estimate. I say this because if it were easy to accurately assess the risk, effort, and value of paying down debt that teams would actively engage it rather than accumulating it. I believe technical debt accumulates, in most cases, precisely because we find it difficult to assess risk, effort and payoff. "If it were easy, we'd have done it." I know me saying this is my own opinion based on experience and that in some cases teams know exactly the risk and effort and the value simply isn't worth addressing the debt. That said, this is one more reason why, in my experience, I do not believe teams should point technical debt. To extend my metaphor further - a made basket in basketball is worth a set number of points: one for a free throw, two for a standard field goal, and three for those beyond the three point line. A steal, like paying off technical debt, may result in points, and it may not. A coach can't tell his team, "If you get this many steals we are sure to win the game." He can look Jimmy Chitwood in the eye though and say, "Jimmy, if you come off the picket fence and make this shot, we win the game." (That isn't exactly how it happens in "Hoosiers" and I realize I've taken this too far, but I can't get this far into a basketball metaphor and not bring up one of the greatest sports films ever made.)
A final reason why I do not see technical debt and business value estimates to be equivalent is that a team can timebox paying down technical debt. For user stories delivering business value there is some discrete level of effort involved in delivering that value. Generally a user story that is 80% done will deliver 0% of its value. (This in itself is probably another blog post regarding the INVEST model for writing user stories.) Paying down technical debt can be timeboxed, though. I could devote half of a sprint to moving my package management to Artifactory. That's not the same as being able to say how much I am delivering, only the time invested. Perhaps I will get two projects done, perhaps it will be ten - I know how long it will take and how much it is affecting the team's velocity in delivering business value, but not how much it will ultimately benefit the team internally. Still, it's perfectly fine to timebox addressing tech debt, whereas it generally is not with user stories.
Ultimately the business is requesting an estimate on when valuable code will be delivered to production. This is kept simple if your user point estimates correspond to business value delivered and technical debt is not pointed. It becomes an exercise in Sabremetrics if you insist on pointing technical debt as you do business value.
No comments:
Post a Comment