Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
How to do quick (or less quick) fixes as Developer
Ahoi!
How do I - as a developer - do quick fixes in SCRUM? Consider this: I code a feature and while I do that I see a bug in an old feature. Or I browse the code and because I have learnt more about the framework I see stuff that is bad style and/or practice. Now I have several options:
- I could just fix it in the feature branch, but this is bad because it would be undocumented and if the feature is reverted in the future the bug or bad code reappears
- I could just ignore it (“does not add business value”), but this is bad because then the bug goes unfixed or we keep bad code around
- I could create a new branch or commit it directly to the dev branch (if it requires only a single commit) but this is bad because then work which is not represented by story points is performed and refactoring might take a while and also the work is undocumented (except for the branch which might be deleted in the future)
How do I progress?
Thanks for any advice,
Tilman
We do allow bug fixes and architecture changes to be included as stories (whether this is acceptable is a matter of opinion, but we allow it for this class) if you can explain to the POs what the business value is. For instance with bug fixes the business value is probably clear, and with architecture changes it might enable certain other features which you know are high in the backlog. However, Scrum does operate on the “You aren’t going to need it” principle, which suggests that large-scale redesign which isn’t tied to specific business value should be postponed until such a time as it really does offer value.
With really small fixes that are easy to implement, it is probably easier to do them than explain them (but not as part of the feature branch).
But this question should remain open for developers to add their thoughts.
So this effectively hinders development because I can’t fix something until the next scrum meeting has been held…
We have been discussing a similar topic and were thinking about the option of fixing it directly (since nobody wants to have bugs longer than necessary) within the feature branche and then convincing POs during the next sprint meeting that there is need for a feature (that then directly would go to the feature archive). In case the POs are convinced that the bugfix added business value, the bugfix can be added to the archive with an estimated effort of 0 (because there was no estimation before) and a real effort like reported by the developer. For larger bugfixes (that still can be fixed within the current sprint), a short call / chat with POs to confirm the business value during the sprint (between two Wednesdays) could be a solution.
However, since this is obviously not the “original process”, we are unsure if this is a acceptable solution for the chair? In the beginning it was mentioned that we are supposed to follow the pure process for some weeks before then we could think about small adaptions based on team consens. Would that be a usecase for this rule?