[H]ow many tasks are there in a sprint and how long should it take to estimate all of them?
Your question has no possible canonical answer. While you can certainly use some rules of thumb to calculate a reasonable upper bound for task volume, there's no universal conversion ratio for stories to tasks, or tasks to man-hours.
For example, a commonly-accepted rule of thumb is that a task should be sized between a half-day and two days so that the done/not-done feedback loop remains tight. Teams can and do violate this rule of thumb, as it is not a framework requirement, but the most successful teams I've worked with all follow the spirit of this rule.
Tasks Per Sprint
I know the answer depends on sprint length and team size, so let's assume 8 developers and three weeks.
This is axiomatically wrong, since the number of tasks is dependent on the number of stories and the quantity and granularity of each story's decomposed tasks. Nevertheless, you can calculate a rough upper bound for sanity checking.
If you assume a priori that:
- each task requires only one developer (this is often not the case)
- 30% of your sprint is consumed by framework overhead (this number varies by sprint length)
- you aren't applying any fudge factors for the fact that productive work hours are generally <= 6 hours per work day
then you have 10.5 "days" available for tasks per developer to allocate to tasks in each sprint. Further assuming:
- 8 developers
- all developers are interchangeable
- there are no queuing activities or dependencies between tasks
- you are including Definition of Done activities as explicit tasks
then following the recommended task-sizing rule would give your team a capacity between 21-148 tasks per three-week sprint.
Avoid Estimating Tasks in Man-Hours
The simple solution here is to avoid estimating tasks in ideal man-hours and toss all the problematic (and often inaccurate) assumptions overboard. By simply not accepting stories into the sprint that exceed your sustainable velocity, you solve most of your sprint planning problems without estimating in hours.
By ensuring that your stories are decomposed into properly-sized done/not-done tasks of no more than a couple of days, you can quickly see if you mistakenly accepted a story that is more complex than your story-point estimate, or if there was hidden work that needs to be documented and re-scoped with the Product Owner during Sprint Planning.
Healthy teams dedicate about half a day to decomposing tasks for the Sprint Backlog. If you don't take the time to do this in the second half of Sprint Planning, then you are much more likely to uncover entanglements, unexpected dependencies, or unplanned work later in the sprint.
A four-hour Sprint Backlog meeting represents less than 3% of your three-week sprint length, and is where most of the design and architectural analysis is done within the Scrum framework. Is shaving that down to 2% by short-changing the task analysis really worth the risk to your project? I'd say no, but your mileage may vary.