Refactoring sometimes means more additional developing and testing work.Especially, performance testing of refactoring part may cross the current sprint. Saving Changes...
This is something team can best figure it out, having said that i do see many team using practice of reserving % of capacity for non user stories work. This principle is also called capacity allocation.
Its like this, you allocate 70% of your sprint capacity to functional requirement and 30% for anything to do with code quality improvement. This allocation can be upfront agreed with Product Owner and can change as situation changes. Saving Changes...
Anna KierczynskaSenior Technical Project Manager| censhareLondon, United Kingdom
Totally agree with Saket - just make sure you have a time buffer during your sprint that you'll use for the improvements. Also, it's good to allocate time for refactoring while you're estimating creating a functionality - there's always a code around that can be improved. Saving Changes...
Don't allow refactoring "anytime." Just because a piece of code can be refactored does not mean it should be done in the current sprint. Refactoring can cause a story's size to double, when you take testing into account, as well. Make the refactoring a separate story that gets sized and prioritized just like other work being done.
This is just one approach. It may not be the best approach for your situation. Saving Changes...
Community Champion
