I'm on a project team of 4 devs, myself included. We've been having a long discussion on how to handle extra work that comes up in the course of a single work item.

This extra work is usually things that are slightly related to the task, but not always necessary to accomplish the goal of the item (that may be an opinion). Examples include but are not limited to:

• refactoring of the code changed by the work item
• refactoring code neighboring the code changed by the item
• re-architecting the larger code area around the ticket. For example if an item has you changing a single function, you realize the entire class now could be redone to better accommodate this change.
• improving the UI on a form you just modified

When this extra work is small we don't mind. The problem is when this extra work causes a substantial extension of the item beyond the original feature point estimation. Sometimes a 5 point item will actually take 13 points of time. In one case we had a 13 point item that in retrospect could have been 80 points or more.

There are two options going around in our discussion for how to handle this.

1. We can accept the extra work in the same work item, and write it off as a mis-estimation. Arguments for this have included:

   • We plan for "padding" at the end of the sprint to account for this sort of thing.
   • Always leave the code in better shape than you found it. Don't check in half-assed work.
   • If we leave refactoring for later, it's hard to schedule and may never get done.
   • You are in the best mental "context" to handle this work now, since you're waist deep in the code already. Better to get it out of the way now and be more efficient than to lose that context when you come back later.

2. We draw a line for the current work item, and say that the extra work goes into a separate ticket. Arguments include:

   • Having a separate ticket allows for a new estimation, so we aren't lying to ourselves about how many points things really are, or having to admit that all of our estimations are terrible.
   • The sprint "padding" is meant for unexpected technical challenges that are direct barriers to completing the ticket requirements. It is not intended for side items that are just "nice-to-haves".
   • If you want to schedule refactoring, just put it at the top of the backlog.
   • There is no way for us to properly account for this stuff in an estimation, since it seems somewhat arbitrary when it comes up. A code reviewer might say "those UI controls (which you actually didn't modify in this work item) are a bit confusing, can you fix that too?" which is like an hour, but they might say "Well if this control now inherits from the same base class as the others, why don't you move all of this (hundreds of lines of) code into the base and rewire all this stuff, the cascading changes, etc.?" And that takes a week.
   • It "contaminates the crime scene" by adding unrelated work into the ticket, making our original feature point estimates meaningless.
   • In some cases, the extra work postpones a check-in, causing blocking between devs.

Some of us are now saying that we should decide some cut off, like if the additional stuff is less than 2 FP, it goes in the same ticket, if it's more, make it a new ticket.

Since we're only a few months into using Agile, what's the opinion of all the more seasoned Agile veterans around here on how to handle this?