Should a 'Refactoring' Product Backlog Item count towards velocity? [closed]

Question

Assuming a refactoring is needed (too big to be incorporated as part of an existing User Story) - is it okay to have a Refactoring 'story' on the Product Backlog?

The purpose of refactoring is not to change the behaviour of the system - so by definition no direct business value is given to the customer.

-- So does the Refactoring 'story' have story points which then count towards velocity or is this somehow cheating?

Context: We did an initial story storing some data in the simplest possible structure. The structure of this data is not going to work for an upcoming user story and requires a different approach, all existing functionality expecting the existing data structure will need to be changed to accommodate this new approach.

Answer 1

In my opinion it's absolutely fine to have this kind of item in your Product Backlog, since I've always taken the PB to be everything that needs to be done for the software to be complete.

I've routinely had features, bug-fixes, refactoring and research tasks in Product Backlogs before. If you don't put it in the backlog, how else would/could the task ever get done? You'll also want to have a definition of 'done' for the task, something that helps describes the aim of the refactoring (make code go faster, make code more test-able, etc.).

Answer 2

I have seen this problem approached in several ways by different teams.

1) Technical debt items (like refactoring) are added to the product backlog as stories, with the user type as 'developer', and business value expressed as direct costs or ROI.

This has the advantage of making the technical debt items (and their business value/reason for existence) visible to everyone, including the customer. It also makes the velocity including necessary technical work be accounted for and visible.

However, they may be too technical for everyone to understand and may waste time for explaining and negotiating these items. The business value may not be apparent or explainable to everyone, especially those who are feature-focused.

2) Reserve one 'special' sprint for technical debt issues.

These are tracked on a technical backlog that is completely separate from the product backlog. This eliminates the need for the team to make the case for them, to push for technical debt items to be added into a business-value based backlog, or for these issues to be forced into user story form.

Disadvantages: there are some in the community who are against any kind of special iteration. It also requires the customer (and everyone) to accept the productivity hit of a 'dark' iteration, in which no visible progress (and velocity) is made.

3) Roll up the time necessary for technical debt into the stories.

This allows the team to only commit to those items that can be completed without incurring technical debt. Story points and velocity will thus include things like refactoring.

The big disadvantage I see to this is that it implies that stories should be completed without technical debt...which seems to violate the principle of only doing enough to complete an item.

Answer 3

This question is kinda outdated but the topic itself isn't so I'll risk an answer.

My take on it is: no, refactoring done as a separate activity shall not be taken into account when calculating velocity, because it doesn't bring a business value and doesn't deliver a usable increment.

The structure of this data is not going to work for an upcoming user story and requires a different approach

I'd then respectively define and estimate the "upcoming user story".