Yes, you do need to estimate twice, but at different times and for different reasons:
Stories should be estimated in story points as soon as they are found. As soon as the PO adds them to the Product Backlog, they should be given to the team for estimating. This can be done in a an ad-hoc way e.g. after daily stand up, or at a regular story-pointing workshop. Doing this allows the PO (and everyone) visibility on the total size of backlog, and allows effective release planning. This also allows the team some visibility of future stories and give input to the PO on options, issues and possible designs.
So that means in sprint planning, the PO and the team can know pretty accurately what stories will be in the sprint, based on their previous velocity. Planning is split into two parts. First the PO presents the next priority stories, the team discusses them and validates the story point estimates. They do this until they have enough to stories in the sprint. This is the Sprint Backlog.
The Second half of the meeting is about taking the Sprint Backlog stories and breaking then down into tasks for the team to carry out. Each task should be small so as to be easily understood and carried out. They should also be estimated in (ideal) hours. This has several uses:
1. Tasks shouldn't be larger than 12 hours (my measure). This keeps tasks small and simple and will highlight problems quickly
2. It gets the team really thinking about how they will implement the task
3. When the team starts the task, they know the time it should take and can raise an issue if they cant meet it.
And of course the team can get another measure of workload against capacity using the total number of hours available to the team, versus the total number of hours for tasks.
So both types of estimates are necessary for different reasons, but doing both in planning is too late for release planning, and makes the planning meeting very long.
Stories should be estimated in story points as soon as they are found. As soon as the PO adds them to the Product Backlog, they should be given to the team for estimating. This can be done in a an ad-hoc way e.g. after daily stand up, or at a regular story-pointing workshop. Doing this allows the PO (and everyone) visibility on the total size of backlog, and allows effective release planning. This also allows the team some visibility of future stories and give input to the PO on options, issues and possible designs.
So that means in sprint planning, the PO and the team can know pretty accurately what stories will be in the sprint, based on their previous velocity. Planning is split into two parts. First the PO presents the next priority stories, the team discusses them and validates the story point estimates. They do this until they have enough to stories in the sprint. This is the Sprint Backlog.
The Second half of the meeting is about taking the Sprint Backlog stories and breaking then down into tasks for the team to carry out. Each task should be small so as to be easily understood and carried out. They should also be estimated in (ideal) hours. This has several uses:
1. Tasks shouldn't be larger than 12 hours (my measure). This keeps tasks small and simple and will highlight problems quickly
2. It gets the team really thinking about how they will implement the task
3. When the team starts the task, they know the time it should take and can raise an issue if they cant meet it.
And of course the team can get another measure of workload against capacity using the total number of hours available to the team, versus the total number of hours for tasks.
So both types of estimates are necessary for different reasons, but doing both in planning is too late for release planning, and makes the planning meeting very long.