Member-only story
Always Refactor? Or Not?
Ticket or not ticket
Refactoring is an extremely important part of coding.
The Boy Scout Rule is to leave things better than you found them — in terms of code quality, readability and of course testing.
How might you set the boundaries of this? Is there a limit to the amount of refactoring that might match a ticket?
The situation
You are creating your new App, Twitter2! Exciting, and the cross-functional team is formed.
The product owner creates the product backlog. The backlog contains several epics, with each epic containing several user stories that are broken into user stories. The product owner has the task of prioritising the backlog, in collaboration with stakeholders to inform a realistic list.
By iteration, the team pulls work to be completed iteratively (through SCRUM methods). The backlog is the foundation for each sprint iteration, and should be added to as we enter a sprint retrospective.
During one such review, we might add several bugs (some messages are appearing twice in the front end — sounds like a pagination error to me).
You might pick out a ticket from JIRA, say to add a new feature to allow 288 characters. This is a crucial feature for Twitter2 — meaning…
