It's not a bug, it's a misfeature. The Product Owner needs to decide how much of a priority it is to address it, and then the entire Scrum Team needs to either build a Sprint around it or squeeze it into the margins as a non-essential work item as capacity allows. TAANSTAFL. You can't have it both ways, and you can't treat new work (which this is) as "free" from either a Sprint Planning or capacity planning perspective.
Houston, You Have a Process Failure, Not a Bug
A developer in my Team misunderstood a user story and built it in a way that they thought was appropriate. However, the Product Owner had something a bit different in mind.
You assume here that this is a "testing" problem of some kind, but your actual description makes it more likely that this is:
- A failure to define a useful Definition of Done for this particular Product Backlog item.
- A failure to follow test-first development practices, such as writing the tests (or use cases) before developing the feature.
- A misunderstanding of the framework. Work that meets the Definition of Done (or the lack of it), and passes all of your defined tests (or the lack of them) is complete. It is therefore impossible for this to be classified as a "bug" since it didn't fail to meet defined expectations, didn't fail to meet contracts with its collaborators (in the software sense of the term), or raise an error on any regressions tests.
- A misunderstanding of "potentially shippable." Just because work is delivered doesn't mean it has to be deployed, so there's some inspect-and-adapt that needs to happen there too.
- Even in a continuous-deployment environment, the inability to toggle a (mis)feature or roll back is a process problem. Bugs and misfeatures happen, but healthy architectures and DevOps pipelines—or at the very least a sensible feature-based SCM branching strategy—all provide processes to deal with them.
All Post-Sprint Work is New Work
In Scrum, stories are never simply carried forward automatically. Even had you caught the misfeature prior to the end of the Sprint, it would still be required to go back onto the Product Backlog to be re-prioritized and re-planned in a subsequent Sprint.
Your case is slightly different, though. You successfully delivered a potentially-shippable misfeature, and someone then chose to ship it. This is therefore not only not a bug in any legitimate sense of the term, but from a framework perspective it's also simply "new work" because the ephemeral time box of the Sprint has expired.
In Scrum, you always start Sprint Planning from where you are now. Not where you wish you were, not where you ought to have been, but from the current state of the Product. Therefore, since you want to change the state of the Product, the work to modify this deployed misfeature is new work that needs to be:
- Prioritized on the Product Backlog.
- Refined like every other Product Backlog item until it meets INVEST and meets your team's Definition of Ready for Sprint Planning.
- Accepted into a Sprint, ideally as part of a cohesive Product Increment that fits both your current Sprint Goal and your team's capacity for the Sprint.
- Estimated ab initio, because it doesn't matter what you've done before. All that matters is how much effort is involved in delivering the new work.
- Decomposed into something suitable for the Sprint Backlog, including an item-specific Definition of Done, a testing plan, and a plan to demonstrate the item during your Sprint Review.
While there are certainly cases where some item of work may not fit perfectly within the Scrum framework—a post-deployment misfeature potentially being in that category—you still need to follow the framework practices as listed above. The only pragmatic variance is that a show-stopper may require that you reduce your planning capacity for producing a cohesive Product Increment in order to make room for the new work needed to modify your misfeature, which may not fit in with whatever central coherence your Sprint might otherwise have.
In an ideal world, you should take a Sprint to not only fix this misfeature, but address your tooling, testing, Definitions of Ready & Done, and other things so that fixing the misfeature is actually part of a coherent deliverable (e.g. righting the ship). In a less-than-ideal world, the only deviation you should consider is treating the misfeature as separate from the Sprint Goal, but that's a process smell in its own right.
Either fixing it is truly urgent, in which case fixing the misfeature and all the process issues that allowed it to happen is the Product Owner's top priority and should be the focus of your Sprint Goal, or it's not. If it's not, then you take it on board when it fits well into another Sprint Goal, or when you have spare capacity, but if it isn't tied to a Sprint Goal then you can't treat it like Priority Number One℠ because it isn't essential to the delivery of the planned Increment.