Are you estimating only your work, or are you estimating as a team? Are you estimating in specific units or finding out how many tasks will fit in the sprint? I ask since the dynamic changes quite a bit:
1/ Just you: I would apply a task breakdown (aka divide & conquer) approach to understand enough that you are confident in the estimate, but without doing all the actual design work, eg: apply your previous experience and familiarity with the product / codebase to help you identify the scope of a task / change (the affected components), then your experience in making changes to those components (well-understood, familiar, unfamiliar, unknown). You now have a picture of how many components, and how well you known them, so you make estimates of each change to the components (often simply a fixed value based on understanding) and add them up (in your chosen units).
2/ With a team: My previous team experience: each team member individually chooses a 'size' value for a task (small - eg half a day, medium - eg: 1-2 days, large - eg: 1 week, too large - whole sprint), then the team comparing those and discovering if there was agreement or that sizing was variable, demonstrating a poorer understanding of the task. For tasks where sizing was matched, a team member would volunteer to take the task on, adding it to their sprint allocation (unless they were out of capacity), for poorly understaood tasks, the team would discuss the scope and apply a similar approach as above to get to a size. Often these more complex or less understood tasks would be shared between pairs of people to reduce risk and improve understanding.
In all cases - I hope you are able to discuss priorities with your team / product owner(s) to ensure that nobody takes on too much in a sprint (or worse, is 'given' too much without negotiation ability), that the team stays healthy and that you get to review how your agile process is working for the team and the company!
Are you estimating only your work, or are you estimating as a team? Are you estimating in specific units or finding out how many tasks will fit in the sprint? I ask since the dynamic changes quite a bit:
1/ Just you: I would apply a task breakdown (aka divide & conquer) approach to understand enough that you are confident in the estimate, but without doing all the actual design work, eg: apply your previous experience and familiarity with the product / codebase to help you identify the scope of a task / change (the affected components), then your experience in making changes to those components (well-understood, familiar, unfamiliar, unknown). You now have a picture of how many components, and how well you known them, so you make estimates of each change to the components (often simply a fixed value based on understanding) and add them up (in your chosen units).
2/ With a team: My previous team experience: each team member individually chooses a 'size' value for a task (small - eg half a day, medium - eg: 1-2 days, large - eg: 1 week, too large - whole sprint), then the team comparing those and discovering if there was agreement or that sizing was variable, demonstrating a poorer understanding of the task. For tasks where sizing was matched, a team member would volunteer to take the task on, adding it to their sprint allocation (unless they were out of capacity), for poorly understaood tasks, the team would discuss the scope and apply a similar approach as above to get to a size. Often these more complex or less understood tasks would be shared between pairs of people to reduce risk and improve understanding.
In all cases - I hope you are able to discuss priorities with your team / product owner(s) to ensure that nobody takes on too much in a sprint (or worse, is 'given' too much without negotiation ability), that the team stays healthy and that you get to review how your agile process is working for the team and the company!
Thanks for your descriptive comment! As of now I'm trying to estimate my work only.