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.

Bozarth

What makes the refactoring too big to be incorporated as part of the User Story? The new data structure a dependency of the User Story. More thoughts on this: ronjeffries.com/xprog/articles/refactoring-not-on-the-backlog – External

This question is off-topic because it's not within the scope for this site, as defined in What topics can I ask about here? Also see: What types of questions should I avoid asking? You may be able to ask on another Stack Exchange site, perhaps Project Management or Software Engineering. Be sure to read the help center's on-topic page for any site on which you intend to post a question. – Selfsacrifice

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.).

Plop

Thanks - my conclusion: ALL types of backlog items get estimated. Story points accrue for fixing bugs/refactoring. If the teams finds refactors are needed/bugs then the size of the work to be done grows accordingly. Our Product Backlog is a Sharepoint List called 'User Story Queue'. Perhaps renaming it (and not using Sharepoint) might help... If possible - attach the refactoring task to the User Story that needs it - so that the refactoring is done JIT and for a purpose. – Bozarth

I agree with this approach. Refactoring is done to improve efficiency and/or maintainability of the code-base, both of which add positive value to the customer/product even if they don't notice it. As such, I would expect it to be included in the sprint velocity. – Cons

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.

Oaten

Regarding point #3, "... which seems to violate the principle of only doing enough to complete an item.". In our team, completing an item means that item must be "Done Done", or, entire Definition of Done must be followed, and if DoD says that code should be refactored to minimise Tech Debt, then refactoring is accounted for in the sprint. Otherwise, if refactoring is not performed, item is not "Done Done", i.e. it cannot leave sprint backlog. – Dickdicken

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".

Svensen