Should the fixing of misunderstood user stories be treated like new user stories or like bugs?

Question

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.

For some reason, we did not test it adequately and it landed on the productive system. Obviously, the takeaway here is that we should have a better testing workflow.

But my question is on something else. Now that we want to fix this unwanted behavior, is the Ticket that we will be creating a Bug or a new User Story?

Answer 1

Focus on how to prevent this from happening again

As pointed out by others, if calling it a bug is contentious, call it a story. That is the easy part. Also, as pointed out by others, I recommend that you focus on how to prevent this from happening again:

• Have you discussed this in a retrospective following the discovery of the issue? What ideas did you get from the team to prevent this, in future?
• Is your team writing 'Acceptance Criteria' in each story? If not, consider doing so.
• Do you have 'User Acceptance Testing' by the Product Owner and/or the concerned business team member? If not, consider adding this to your process. Testing by a dev team member tends to be whitebox testing, while testing by the PO/business person tends to be blackbox testing.

Answer 2

Doesn't really matter. Just be consistent.

Scrum (I'm assuming you're using Scrum, given the 'Product Owner' tag) doesn't differentiate between bugs and user stories. It really just depends on how your specific business wants to track things.

More than just your testing failed.

Generally, by the end of the Planning Meeting, the entire Scrum Team should have a shared understanding of the work in the Sprint.

Ideally, this should have been caught at the beginning of the Sprint, before the developer even started working on it.

Answer 3

Does it really matter how you classify it? Regardless of if you call it a "bug" or a "user story", the end result is a change to the system. In some environments, maybe it does matter, but in others, it may not. If you don't need to make the distinction, then I would eliminate it entirely.

If you do need to make the distinction, I'd prefer to call it a "bug". Or, more accurately, a "defect". The system is performing as it was designed, but the design of the system is incorrect.

I'd also suggest a deeper root cause analysis before saying that you need a better testing workflow. The next step would be to determine why the developer misunderstand the user story. Adding or changing testing is adding inspection activities. You can't inspect quality in, you need to build it in from the beginning, which starts with a shared understanding of the system under design, high-quality requirements, and collaboration across the team throughout the development process.

Answer 4

As a rule, try not to differentiate bugs from other stories. What matters is what you want to do about the issue in question and what priority it has. The development team should feel free to label things as a bug if it helps them but that kind of label can be contentious so it may be better simply to label everything as a story.

Answer 5

There is something that needs to be done for the product. You can convey that information no matter what the ticket type is. Scrum doesn't say anything about stories or bugs. It just has a Product Backlog Item that will become a Sprint Backlog Item.

In the Scrum framework process is left up to the people doing the work to decide.

So I will say your team should decide what they want to call it for better understanding and to avoid a repeat of the said misunderstanding.

Answer 6

Since a there was no common understanding, the developer will prefer the change as new user story as creating a bug will indicate a failure on his part. (all said and done someone is still watching the quality of deliveries and keeping count of defects/bugs). Focus should more importantly be on preventing this sort of thing from happening again as the code seems to have slipped through testing, where someone did not do what is expected of them.

Answer 7

TL;DR

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:

1. A failure to define a useful Definition of Done for this particular Product Backlog item.
2. A failure to follow test-first development practices, such as writing the tests (or use cases) before developing the feature.
3. 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.
4. 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.
5. 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:

1. Prioritized on the Product Backlog.
2. Refined like every other Product Backlog item until it meets INVEST and meets your team's Definition of Ready for Sprint Planning.
3. 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.
4. 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.
5. 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.