When using Scrum, are the estimated story points for completing an User Story sufficient, or should the estimate be taken at the task level?
The Scrum Guide states that:
Product Backlog items have the attributes of a description, order, estimate, and value.
Note that Scrum does not define the units for an estimate (Story Points, calendar hours, ideal hours, or something else). It also doesn't say that the estimate needs to be numerical. The purpose of the estimate on the Product Backlog Item is to assist the team during Sprint Planning. The team needs to be able to determine or forecast how many Product Backlog Items it can complete in a Sprint. Anything that can satisfy the team's need for being able to plan the Sprint can suffice as an estimate.
To answer your question, you would need to ask the team. What would they need to do in order to ensure that the team and stakeholders understand what is required to complete the work and successfully plan a Sprint?
Story point estimates and estimates at task level often have different purposes.
Story point estimates are primarily about working out the capacity of a sprint. They provide a lightweight, metrics based approach to ensuring that the team does not over-commit.
Task level estimates are more often used for the following:
- To aid the team in planning how the work will be done - for example knowing when a particular coding task will be completed might help with planning testing.
- The discussion needed to arrive at a task level estimate can itself be valuable. By exploring the details of tasks the team might drive out discovery that they may not have otherwise spotted.
- If the team contains specialists (e.g. front-end developer, database administrator, etc.) then task level estimates can ensure no specialist is over or under loaded.
Task level estimation costs time and resources though, so you need to be careful that the benefits you get from doing it outweigh the cost.