This is a question that was posted on a discussion list online. The poster asked if Technical Debt should be assigned story points and the post gave two examples: “building a staging server” and “cleaning up code”. Below is my answer.
Story Points and User Stories are not a part of Scrum. They are simply one way of many of representing estimates and requirements(known in Scrum as Product Backlog Items)(PBI’s) that characterize changes to the software product under development. User Stories describe requested functionality of the system under development that primarily benefits users or other stakeholders *outside* the dev team.
My sources here are: Scrum [_The Scrum Guide_, Schwaber et. al], User Stories [_User Stories Applied_, Cohn]
So, in summary, the proposed change must be:
a) primarily beneficial to some stakeholder outside the dev team (Remember, the PO is not technically part of the dev team, so they can be an external stakeholder.), AND
b) a change(some feature or functionality) in the product itself, i.e. in the system under development.
In Scrum, when using User Stories to represent PBI’s, the PO ultimately owns the priority and description of the PBI, while the dev team owns the estimate of the PBI.
The PO also owns the maintenance of the PB, so ultimately it is totally under their control whether something makes it onto the PB. In short, all proposed PBI’s must be approved by the PO.
So, if you use User Stories to represent Product Backlog Items…
* cleaning up code – this sounds like “Undone work” to me. See the section in the Scrum Guide on “Final Thoughts” and “Done.” Most people have to read those sections 2-3 times for it to really sink in. Pay attention to every word closely. There is no short answer here, so the best I can do is say to read the Scrum Guide.
Note that I use the term “Undone Work” instead of the term “Technical debt.” This is because “Technical Debt” doesn’t mean precisely the same thing as “Undone Work” as described in the Scrum Guide. They are two entirely independent terms. In fact, “Technical Debt” is not really a well defined term at all, which is why I’m focusing on the examples the original poster gave.
* building a staging server – this is not a change to the product itself, so therefore it is not a User Story and should not go on the PB. It can, however, be tracked as one or more tasks on the *Sprint* backlog in one or more Sprints.
There are some subtle but *very* important points here. Sometimes there is work done by the dev team that cannot be directly mapped to a User Story or the Product Backlog. There’s nothing wrong with that. As such, when (Release, Sprint, or any other kind of) planning, it’s important to take this “other dev work” into account. If you want, you can represent it as tasks on the Sprint Backlog. Another result is that the PO doesn’t prioritize or control this “other dev work”, the dev team does. In addition, recall that the dev team also owns deciding how much PB can be taken on in a sprint. So, if your team decides you want to spend half of your sprint doing this “other dev work”, that’s up to the team, and NOT up to the PO. Remember, though, that this decision will be made visible, so make sure you can justify your actions.
One Strategy: “Dev Team Time”
The best practice that I’ve witnessed is that the PO and the dev team make an arrangement whereby roughly 20% of the time in each sprint is allocated for doing whatever the dev team wants to do(note that I didn’t say “work” or “technical debt” here, it can be anything the team feels compelled to do.). Let’s call this “dev team time.” This 20% number is just a starting point for a conversation and collaboration related to Release and Sprint planning, and the number can vary highly in either direction, so long as the final allocation is determined by the dev team.
I further encourage teams to adopt the goal for this time to be something like “anything that has a good probability of helping the productivity of the dev team.” It could be technical debt, exploring new technologies, having a team building event, etc. The dev team is “self organizing”, so this is a great chance for them to exercise those self organizing skills. I also encourage them to make this time visible by creating tasks in the Sprint Backlog to represent the tasks or time it requires.
Note that this practice is not specifically a part of Scrum in the Scrum Guide, but is a technique within the Scrum framework (Quote from the Scrum Guide — “…rather, it[Scrum] is a framework within which you can employ various processes and techniques.”). I believe this practice to be consistent with Scrum’s roles, rules, and principles, etc. Said another way, I do NOT consider this practice a modification to the Scrum framework, but a technique within the framework. This is an important distinction.
If you find yourself wanting to make a list of all the ideas your team has for “dev team time” then do so, but I recommend you *DO NOT* use terms like backlog, story, points, or any Scrum term to describe them as this will almost assuredly cause confusion.
May the Sprint Be With You!