8

What should we do for user stories for technical debt in Pivotal Tracker? Should we consider these as features (giving points) or as chores (giving no points, thus lowering velocity)?

I am confused what should be considered as a chore:

  1. Duplication of Code - It's clear that if we have put same code in multiple places, that's really bad code practice and indicates developers in the team should give more thought to make software maintainable, do refactoring and team should spend time on code reviews. As all this would take maturity, time and code level experience, it's better to deliver less number of points so that code quality is not compromised. So, such mistakes should be penalized and velocity should be lowered by not giving points to chore.

  2. Technology upgrade - Like moving to modularize JS, HTTP2, React, MVC or any other new/better technology. These steps will make performance and maintenance of the code better. But should this be chore or feature? I believe this is how technology world is, new technologies come every now and then and you have to migrate to it. So, I see no point in penalizing team's velocity for such work. Suggestions?

  3. Duplication/Sub-Standard code in legacy code - Few code are which are untouched since long time OR when a new team is formed but the code base is a bit old, we face this challenge. The team says they have not coded this section so why should their velocity be penalized by picking such technical debts as they never created those debts.

  4. Sub standard code due to business urgency - Sometimes developers are forced to push features ASAP on live due to competitors/targets/business/user pressure. Should cleaning up of such bad code be considered as chore (w/o giving points) too? This time development team is not at fault, so why should their velocity be pulled down, when in fact they mostly put extra hours in such cases.

I believe all types of chore mentioned above, if done wisely, should improve team's velocity in future. But how should we keep balance b/w maintaining team's velocity as well as penalizing for the technical mistakes team is doing by taking bad decisions?

The question is similar to: Should technical debt be scheduled as a feature or a chore (or a bug)?, but I didn't find convincing answers that cover all 4 points so I am reposting it in a different manner.

jonrsharpe
  • 1,318
  • 2
  • 12
  • 17
maverick
  • 341
  • 2
  • 10
  • 2
    If you're not actually delivering new functionality for end users, it's not a feature. A fall in velocity due to a team choice to pay down technical debt isn't a penalty, it's useful information. (Disclosure: I'm a Pivot.) – jonrsharpe May 12 '17 at 19:21
  • should technology update like moving to http2 which improves performance & MVC which improves SEO, performance, mantainance be considered as chore and not given points? – maverick May 12 '17 at 19:24
  • should technology update like moving to http2 which improves performance & MVC which improves SEO, performance, mantainance be considered as chore and not given points? – maverick May 12 '17 at 19:25
  • 2
    Your users probably don't care about your SEO. Performance maybe, if you've validated a user requirement to improve loading times then that would be a feature. But refactoring or switching platforms, presumably in the hope that you can deliver better features faster *in the future* is not a feature; you'll "get those points back" when you do deliver those features. – jonrsharpe May 12 '17 at 19:27
  • 2
    @jonrsharpe: The care and feeding of your users notwithstanding, why would you schedule *anything* without also assigning a cost to it? I'm not sold on the idea of mysteriously losing velocity due to technical debt that's being paid down without story points just for the sake of "correctness." – Robert Harvey May 12 '17 at 19:53
  • @RobertHarvey: I believe its small way to penalize bad tech decisions. This encourages team to think long term. And what's the harm in losing velocity if you get a lesson through it. This gives team a reason to retrospect and find why they lost the sprint. – maverick May 12 '17 at 20:01
  • 2
    Voting to close as primarily opinion based. Either way is fine, and in the end this is all paperwork to aid you in getting things done. – Telastyn May 12 '17 at 20:04
  • @jonrsharpe: It becomes tricky when team dedicates multiple sprints to deliver only SEO. Why shouldn't such things be counted in for points? This brings more users, fetches business. Although I agree, it doesn't add value from users perspective but it definitely helps in generating business. – maverick May 12 '17 at 20:04
  • 1
    @sahil: Ouch. Incurring technical debt is something that can often be out of the software developer's control. Management pressures to release software on a certain date can be one reason. Why should they be penalized for that at all? If it's worth doing, it's worth assigning a cost. – Robert Harvey May 12 '17 at 20:05
  • @RobertHarvey: What you are suggesting is that everything that is worth doing should be assigned a cost/points. If bug is worth doing, then should it be assigned cost/points as well? Assigning bugs/chores is highly discouraged by Pivotal as these are something that should pull back team and give team an indication that something is wrong which needs to be corrected. – maverick May 12 '17 at 20:12
  • Yes, that's exactly what I'm suggesting. If Pivotal discourages that, then they must have some mechanism other than story points for tracking that time. Do they? – Robert Harvey May 12 '17 at 20:14
  • @RobertHarvey I don't see a fall in velocity as a penalty, or a team decision to spend time on things that don't deliver points as mysterious. – jonrsharpe May 12 '17 at 20:15
  • @jonrsharpe: Fine, but this isn't really about optics, it's about tracking time. How do you do that? Are there "chore points?" – Robert Harvey May 12 '17 at 20:16
  • 1
    @sahil if you're dedicating multiple sprints (weeks? Fortnights?) just to improving SEO then you *should* see the velocity fall, and think about *why*. Maybe you should schedule some user stories alongside that work, so that your current users don't feel like the app is stagnating? Or if that really is more important to the business than the end users, then that's a decision you've made. – jonrsharpe May 12 '17 at 20:17
  • @jonrsharpe: Does management care about any of that, or is it merely a developer concern? Can you take falling velocity to management and make the case that "We need more time to pay down the technical debt?" Or do you simply keep it swept under the rug so that management never sees a bad velocity? I'm not sure I understand the motivations here. – Robert Harvey May 12 '17 at 20:18
  • @RobertHarvey we don't use points for tracking time, maybe that's the fundamental difference here. No, we don't have chore points. In general we are in autonomous teams working on a single project, so the management is the product manager we've agreed the backlog priority with. We don't sweep it under the rug; if external stakeholders ask why velocity has fallen, we can show them what we've been working on in the backlog and tell them why we made that decision. – jonrsharpe May 12 '17 at 20:22
  • @RobertHarvey: Pivotal gives you provision to manually adjust the velocity. So for example if you deliver 50 points in a sprint but you want to dedicate 50% team to bugs/chores, you can re adjust your velocity to 25 points and commit 25 points work to the PO. – maverick May 12 '17 at 20:30
  • That seems reasonable, though I suspect you're not really tracking the 25 bug/chore points, but merely discarding them, in which case you might as well just let the velocity fall naturally. – Robert Harvey May 12 '17 at 20:30
  • @sahil but then you might as well just point the chores. You should adjust team strength for e.g. absences, not to try and make it look artificially look like you're delivering points you aren't. – jonrsharpe May 12 '17 at 20:33
  • @RobertHarvey: I'm not sure if you got it completely but this feature only helps team to plan better and make realistic commitments. The burnup chart still expects team to deliver 50 points but team will deliver only 25 due to chores/bugs and due to this their next sprint velocity would fall. – maverick May 12 '17 at 20:33
  • @sahil: That sounds like a distinction without a difference. If your velocity is going to fall naturally by 25 points anyway (and you already know that), why bother telling Pivotal? Is that merely a notation? – Robert Harvey May 12 '17 at 20:34
  • @jonrsharpe: please read my last comment, we don't make chart look artificially good by reducing team strength in such cases, that is to just estimate and give realistic commitments. The team strength is 100% but team would picks only 50% of the sprint's task so they loose as per velocity chart at the end of the sprint – maverick May 12 '17 at 20:36
  • Now I think we're overthinking this. If Pivotal says this is how it works, then this is how it works. It is, after all, the tracking tool you chose. – Robert Harvey May 12 '17 at 20:37
  • @RobertHarvey: It helps in picking only 25 points features so that we can deliver business as per commitments – maverick May 12 '17 at 20:37
  • But you just said that your commitment is still 50 *feature* story points. So what difference does any of this make? – Robert Harvey May 12 '17 at 20:38
  • Yes and I mentioned that we inform stakeholders that we will only pick 25 this time as rest bandwidth would be dedicated for bugs/chores – maverick May 12 '17 at 20:39
  • Well, I guess you've already gotten your answer anyway. Technical debt is a chore, and chores are not assigned story points. – Robert Harvey May 12 '17 at 20:52
  • Are you letting a tool define your process? Is PT a tool or a process? I find it moronic to believe that fixing bugs provides no business value. If your software is full of bugs, you won't have any customers. Having to justify the idea that fixing bugs has business value beggars belief. Try leaving the bugs unfixed and then see what happens to your business. You could argue the same for "chores". Take for example migrating a site from http to https. Sounds like a chore right? What will happen to your business on the day your biggest customer has their credential stolen at a coffee shop? – RibaldEddie May 13 '17 at 03:48
  • Another way of thinking about this is that if you think something is worth doing _at all_ then it should have a quantifiable business value. If you've got a process that allows you to do work that has no quantifiable business value, why are you doing that work, let alone why are you using that process?! If using Pivotal Tracker requires you to adopt their process, you're giving up your project and product management to an outside organization. – RibaldEddie May 13 '17 at 04:18
  • Everything that the Agile manifesto stands for seems to be thrown out when using a tool that forces a process on you and throws a scary warning at you when you try to override it. – RibaldEddie May 13 '17 at 04:19
  • @RibaldEddie it's not that fixing bugs has no value, it's that you already claimed to have delivered that value in a previous story you had pointed. Points aren't the same thing as business value, all of the work in the backlog should have business value. – jonrsharpe May 13 '17 at 07:16
  • @jonrsharpe yes and you have two separate concepts there. All items in the backlog that will be included in the sprint should be pointed so as to have a complexity estimate attached to them, so that the total amount of work committed to by the team is clear. As to the business value-- well if a bug or chore is less important to the business than the next great feature, then by all means go ahead and work on the feature. But if your project management software _actively encourages this practice by not giving credit to the team for the effort spent on the maintenance task_, you have a problem. – RibaldEddie May 13 '17 at 07:31
  • @jonrsharpe the idea that all bugs or chores are caused by previously pointed work doesn't hold water with me. If Microsoft releases a browser update that breaks a feature of my web app, does that mean that the chore to update the API or come up with a workaround shouldn't count towards the sprint goal? It shouldn't have a point size associated and the work should count as a drag on the team velocity? It sounds to me that a manager that wants to use this as a software development process is incompetent. – RibaldEddie May 13 '17 at 22:42
  • @RibaldEddie I didn't say chores and we don't do sprints, but thanks for the kind and constructive feedback. – jonrsharpe May 14 '17 at 07:42
  • @jonrsharpe I realize that's harsh and I hope you won't take it personally. I think you have to be aware that there are software companies in this world that commonly tell their devs that they have to make a choice between spending the weekend at the office working unpaid overtime or else they lose their jobs. Something similar has happened to me at some previous employers. So maybe I have a chip on my shoulder. Software development management is not something that is easy to get right. – RibaldEddie May 14 '17 at 15:22
  • @jonrsharpe , RibaldEddie: I have got my answer. It's right that this can be implemented differently by different companies but I believe giving no points to chore/bugs make more sense in our scenario. The rule of thumb we will pick to classify something would be "Is it something that user wants? Is it something that would take the product forward for user?" Moving to https, technology update is good from dev point of few but doesn't add direct value to the user. I will try to implement this in my scenario and post here if we face some challenge. Thanks for the valuable time and discussions. – maverick May 14 '17 at 15:29
  • @sahil one day you are going to have a big problem. Take for example what just happened with the WannaCry malware attack worldwide. MSFT released a patch for this in March. If I used your process in a shop with a DevOps-style unified team, then all of my team would get no credit for the effort to apply the patch-- since of course where is the benefit of the user? So why would my team ever do the chore?!?? To management, the chore is nothing but a waste of time. Over time the team will learn to "maintain velocity" and the infrastructure will rot. In a young team the whole product will rot. – RibaldEddie May 14 '17 at 19:19
  • @sahil also I question your management's understanding of the marketplace if they think that https doesn't have direct benefit for the user. – RibaldEddie May 14 '17 at 19:21
  • @RibaldEddie: Points has nothing to do with the work being picked or not. The work would be picked in the order of its importance from user's perspective. If enhancing security is the first priority, then https/security tasks would be the first priority. But this would not be given points as it adds no direct value to ordinary users life. As a user, I feel product I am using is safe. What matters the most is how that product simplified my problem/llife. – maverick May 14 '17 at 19:29
  • Possible duplicate of [Should technical debt be scheduled as a feature or a chore (or a bug)?](https://softwareengineering.stackexchange.com/questions/78998/should-technical-debt-be-scheduled-as-a-feature-or-a-chore-or-a-bug) – gnat Aug 07 '18 at 14:25

2 Answers2

8

Short answer: paying down technical debt is a chore. You're not delivering new functionality for end users, so it doesn't get pointed.

Official answer:

Bugs and chores aren’t estimable by default

Feature stories are estimated because they contribute to business value. Bugs and chores are considered part of normal software product overhead—they emerge over time, and are continual overhead, an ongoing cost of doing business. Tracker’s automatic velocity calculation accounts for this as a built-in cost, and estimates how much business-valued work can be completed each iteration. This lets you focus your planning on business value, risk, and priorities. Therefore, bugs and chores in Tracker are not normally estimated. You can enable estimation for bugs and chores in Project Settings; however, we strongly discourage turning on bug and chore estimating. You cannot turn it off later if you change your mind.

https://www.pivotaltracker.com/help/articles/planning_with_velocity/#bugs_and_chores

This is why stories classed as bugs and chores can't have estimates assigned to them with PT's default settings, but I think also explains why you shouldn't count these tasks as features just to get points for them.

Firstly, I don't think you should count a fall in velocity as a penalty: it's just information. Perhaps it was something natural, like a new person joining that you had to spend extra time training. Perhaps it was something unexpected that reduced your capacity (e.g. illness) or consumed extra (e.g. "stop the world" bug). Perhaps you just hadn't estimated the features well, for whatever reason; this is something you can learn from. Or perhaps it was because you decided, as a team, to prioritise paying down some technical debt over delivering new features (and maybe incurring more debt).

Secondly, it's not necessarily a mistake to incur technical debt. It's not ideal to incur it accidentally, but if you decide to e.g. build the "quick and dirty" thing now in the knowledge that you'll need to tidy up later, for instance so that you can get more user feedback or meet a hard deadline, that's a deliberate choice you've made as a team and is OK.

As to whether something should be a feature, a simple rule of thumb is: do the end users care? You mention improving SEO: is this something they're at all interested in? Performance they might well care about, but on the other hand maybe they'd rather have some new feature than the same stuff with a few hundred milliseconds off the load time. Do some research: go and ask them what they want. Let them help you to prioritise what it's best to spend the team's time on.

You might decide that your current technology choices are holding you back from delivering certain features as efficiently as you'd like, in which case it's perfectly reasonable to (again, deliberately) spend time migrating all or part of the application over to something new.

I believe all types of chore mentioned above, if done wisely, should improve team's velocity in future.

Here I absolutely agree with you, but then isn't getting points for these chores double-counting? If you're doing the work so that you can deliver more features later, then you should see the higher velocity after you've done it, not while you're doing it.

Also, things like code reviews and basic refactoring in the process of delivery (e.g. the "refactor" part of the TDD cycle) should already be part of your ongoing work and therefore already included as part of the team's overall velocity.

Disclosure: I'm a Pivot, working for Pivotal Labs in London, but not on the Tracker team.

jonrsharpe
  • 1,318
  • 2
  • 12
  • 17
  • Stories aren't estimable either. That's the reason story points and velocities exist. – Robert Harvey May 12 '17 at 20:17
  • @RobertHarvey sorry, to be clear that quote isn't saying that it's impossible to estimate bugs and chores (or possible to estimate features, for that matter!) but that by default in PT you can't *assign an estimate* to a story that isn't classified as a feature. – jonrsharpe May 12 '17 at 20:25
  • 7
    "You're not delivering new functionality for end users, so it doesn't get pointed." Sticking to this dogma is the primary mechanic behind the buildup of technical debt. Work is estimated and done for stake holders which are not necessarily end users. You can have a story like "Refactor this code (what), in order to keep it maintainable (why) for the development team (for whom)". – Martin Maat May 12 '17 at 20:44
  • 1
    @MartinMaat I disagree; *saying that velocity must never fall* would do that. You're free to write your chores the same way as your features, but that doesn't give them user value. – jonrsharpe May 12 '17 at 20:48
  • @MartinMaat Agree 100%. This reminds me EXACTLY of Eric Evans' "Responsibility traps" talk from InfoQ some years ago. https://www.infoq.com/presentations/design-strategic-eric-evans – RibaldEddie May 13 '17 at 05:35
  • @jonrsharpe the problem is that most organizations DO believe that velocity must never fall. The layer of management immediately adjacent to the dev team might say otherwise, but it's lip service and after that, when you have non-technical management, they are clueless as to the value of the unpointed work and will judge teams or individuals based on that ignorance. – RibaldEddie May 13 '17 at 05:36
  • @jonrsharpe We do agree. I wanted to point out though it is a flaw in Scrum (or the way it is generally understood and applied) that all stories must be user stories. Formally and with enough creativity, a user story can be written to address technicals debt because it will ultimately be in the user's interest but this will not happen because the operation has already trickled down to a pipeline that is being fed by complaining users, of wich output is passively being processed by a team of zombies. Code ownership and a sense of urgency for design will have been killed in the process. – Martin Maat May 13 '17 at 06:17
  • @MartinMaat my guess is that the type of user story that you describe is created for two reasons: first is that someone is comparing "business value" and "user value" without defining those concepts properly. Second is exactly because the rule in most companies is that a low velocity is always bad to upper management. So the team wants to point all of their work. So what is the reason to have points and velocity at all? If points are about relative complexity so as to estimate without mentioning time, then pointing bugs or chores is perfectly reasonable and necessary. If... – RibaldEddie May 13 '17 at 06:28
  • ... If the reason to have points is so that stakeholders can overstuff their desired features in a sprint and gamify the devs to get the burn down chart to zero, and then club them for the next sprint: "team, our velocity was down 15% last sprint, lets work extra hard this sprint to make up for it!!!", Then congratulations you're working in a sweatshop that one day will collapse due to all the accrued debt. And yes I have worked in such places and have zero desire to again. – RibaldEddie May 13 '17 at 06:32
  • @RibaldEddie "So what is the reason to have points and velocity at all?" The purpose of assigning points to stories is to get better at planning/estimating work, to get predictable, and to ultinately be able to maintain a sustainable pace as a team. But again, this is a Scrum practice that WILL be misunderstood and abused. – Martin Maat May 13 '17 at 06:42
  • @MartinMaat indeed, remember that Scrum actually talks about PBIs, not stories. So pointing anything in the backlog regardless of whether it is a story, bug, or chore or whatever should be done if it comes from the product backlog. Since another rule of Scrum is that ANYONE can add items to the backlog, if a dev team member wants to add a task like "upgrade the infrastructure" then, as long as the product owner agrees on the priority that it should be done, then it should be pointed. And in Pivotal Tracker's process, that's not possible. So it's not Scrum, and it will hurt your team. – RibaldEddie May 13 '17 at 06:47
  • @jonrsharpe do you think it's fair to say that Pivotal isn't Scrum, it's its own process? – RibaldEddie May 13 '17 at 06:53
  • @jonrsharpe https://www.scrumalliance.org/community/articles/2007/march/glossary-of-scrum-terms#1130 in Pivotal, does a chore or bug not appear on the backlog? – RibaldEddie May 13 '17 at 06:57
  • @RibaldEddie it's *not* Scrum, Pivotal practices XP. All stories are prioritised in the backlog, but only features are estimated and not all stories must be user stories. – jonrsharpe May 13 '17 at 07:10
  • @jonrsharpe honestly it sounds like this entire post can then be reduced to a helpdesk question about Pivotal Tracker. I'm not convinced it's XP personally, as that is a vague term that historically was associated with the development practice and not project management. To be honest I'm not even sure it's all that Agile, since the tool itself encourages and enforces a particular process. It seems weird to me that it could be Agile and yet every single team that uses the tool is constrained in the same way. I would expect an Agile tool to be used in many different ways by teams. – RibaldEddie May 13 '17 at 07:16
  • @RibaldEddie XP is a specific set of values, principles and practices. PT *is* pretty opinionated, but that's partly because it supports the consultancy practice where we're generally working with teams in an early stage of the transition to agile ways of working, so I'd agree with encourages but say enforces is a bit much. – jonrsharpe May 13 '17 at 07:26
  • @jonrsharpe well there is a bit of an implied threat there: you can enable this feature and be able to point these other types of things but (insert spooky voice here). *there's no going back*. . One thing I do believe is that the product owner role, the "decider" on business priority when there's no consensus or outright conflict on what should be done next, that's a very important role. I shudder to think that the tool would be so opinionated as to punish one choice over another. It's too close to a "one size fits all" approach for me. – RibaldEddie May 13 '17 at 07:47
4

Just to be contrarian, we handle bugs and technical debt as any other PBI. In fact, we don't even have a "bug" type. Everything is a PBI. Our backlog is ordered by business value assigned to the PBI. As a result, a prominent user-facing bug that is causing problems will have a high business value assigned to it, since you risk losing money with something like that, and it will likely be one of the first things done. On the other hand, a bug that doesn't really have much impact and isn't affecting the bottom line will have a relatively low business value and may not be fixed for a while. That's an important mental wall that should be torn down: not every bug should be fixed. Sounds like sacrilege, I know, but if the effort involved in fixing the bug is more than the business value fixing it will bring, then the ROI is negative. Treating everything as a PBI gives you the freedom to make these types of empirical decisions without being distracted just because it's a "bug".

Likewise, with technical debt, there very much still is a business value in play. Some technical debt may be incurred with very little cost and may remain long-term, but some technical debt will kill your business over time, and therefore has a very high business value. The key again is realizing that everything is just a PBI. Everything goes into the backlog and you work on items in that backlog based on the value they add to the business. Whether it's a feature, a bug, or technical debt is really beside the point.

This also has the benefit of sidestepping your question entirely. Since everything is a PBI, everything contributes to velocity. The idea of doing work that's not actually sized and counted in your velocity is kind of insane to me. You're basically creating a huge blackhole in your empirical data. Velocity is already a pretty rough metric, it's an estimation based on an estimation based on even more estimations. Add in a bunch of variable amount of work not being tracked, and now the number is all but meaningless. Everything your team does in a sprint is part of your velocity.

Chris Pratt
  • 6,374
  • 3
  • 14
  • 13