Just wondering on some agile best practices. Do you guys estimate efforts for defects? My PO is totally against it and says we deliver 5 to 7 pointers user stories + fix all the defects from previous sprint and current sprint, which I feel is over burdening the Dev team + in hurry to complete current sprint stories delivering poor quality work, which in turn become defects in the next sprint 😨 caught in this loop for a while now 😫

Any ticket that can not be solved in 5 min, should be effort estimated. Especially since tech debt that is hidden under "defect" will suck up the team time.
Your PO tried to push for everything - both features and stability/bug fixes. He will end up with nothing, and will blame the team for not delivering.
Put a paper trail in place: Send an email that says that you need to maintain balance, or stand the risk of failing to deliver - PO needs to aknowledge the mail.

Also - something that I learned a long time ago: managers (phb type) will try to extract the maximum effort before adding resources/reducing the load. Solution: Fail, and blame lack of resources/over commitment. If the PO refuses to change - Fail again. Make sure he, and those above him know that it is his fault. Eventually he will get the message.

Sounds like you're doing Scrum (stories, story points, sprint). In Scrum, a sprint is supposed to be fixed. The team should be confident in saying "we can finish this in two weeks with good quality" (or whatever your sprint length is) and then work uninterrupted. That may mean you need to say "no, later" to stories in planning, including bugs from earlier sprints.

Furthermore don't add new stories during a sprint. "fix defects from current sprint" sounds like you do. Which might be the reason you feel overburdened: You agreed on a certain amount of work, but it keeps growing.

In my experience bugs generally can't be estimated. With stories, you have a rough idea about its complexity (which is what you estimate - not time). For bugs that isn't always the case. You need time for analysis, writing tests and fixing, each of which can take much longer than expected. So you can push back against your PO in some cases.

@magicMirror
> Solution: Fail, and blame lack of resources/over commitment. If the PO refuses to change - Fail again.

Agreed! In general, one needs to become comfortable with the fact that you sometimes just miss the sprint goal. Mistakes not being allowed means you have a terrible "error culture". In a good one, you make mistakes, you learn from them, and life goes on.

Scrum is so incredibly retarded. YMMV.