Our team using Scrum three iterations. We successfully estimate PBI in storypoints using poker-planning. But next we cannot do anything because we don’t know
- Who create tasks? PBI is created by everyone and approved by product owner, but what about task
- Who estimates task?
- What technique should be using for task estimating? Poker planning are good for PBI estimating
Think about why you are estimating the tasks in the first place; what is the point if you’re already tracking the teams progress via story points and velocity. In my opinion, it is secondary to story level estimates.
The point is you want to track the progress of the team in the current iteration. In theory, people are better at estimating smaller chunks of time. The estimates are usually used to create a burn down.
These estimates should have little impact on the macro-level, story points, which makes them a bit redundant. Don’t get me wrong, a some redundancy is OK. You need checks in place to make sure that you’re original estimates are sound.
To answer your specific questions:
- The tasks are created by the team who are going to implement the stories. You don’t have to do this as a full team, but you could break up to smaller teams to do this. I find it is best not to involve the whole team in this.
- The people who write them. It is better if you don’t have just one person estimating a task.
- If there is any uncertainty I find a small spike (hours rather than days) to be effective. A team member is tasked with looking at the code and coming up with a breakdown. You could argue that this should have already happened when the original estimate was made, but I find those estimates can be correct even if there is some disagreement about how a story should be implemented. However, for most tasks, I found Planning Poker to be effective.