I work on an agile project using Scrum.
Sprints have come and gone and we have fulfilled milestones successfully. The system works well enough to meet the current customer requirements.
However, we are left with a system in serious need of refactoring, as much of the development was performed with little eye on the future (instead the focus was on the sprint at hand).
How best to deal with this? Sprint(s) dedicated to refactoring?
Yes, the occasional one of those is sometimes not a bad thing. But if you're agile using Scrum, then you are presumably trying to follow Test-Driven Development (TDD), and it is important that you remember that the sequence is red-green-refactor, not just red-green. Bad quality code is not the output of agile development, but of poor agile development.
Do you have a definition of 'done'?
When you have finished coding and are ready to check in, you should have met your teams definition of 'done'
This definition should amongst other things include meeting your acceptance criteria / code review / test review / and meeting agreed coding standards.
If after several sprints your code base is in need of serious refactoring I would suggest your definition of done needs reviewing.
Here's an article from Scrum Alliance on defining your 'definition of done'
You don't necessarily need to dedicate a whole sprint to refactoring, it can also work at the task level. When you have a story that requires working with some hairy piece of code, include a refactoring task in that story as a kind of prerequisite for getting anything sensible done with that part. That way, you make progress with the features but also get some refactoring done incrementally.
For my team I typically start a refactoring sprint roughly once every three to four months. Considering we run 2-week sprints, that's one refactoring sprint roughly every seven sprints.
I run the refactoring sprint like any other sprint - strictly 2 weeks time limit. Sometimes we even run just 1 week refactoring sprints (when something urgent comes along).
A note on refactoring sprints: don't be too ambitious:
This is what I personally use as a guide to refactoring. It not only make refactoring managable but also serves as a good indicator for when you're overdoing it.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With