Agile estimation phases [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 8 years ago.

Improve this question

I have confusion around the following elements of Agile estimation:

• Should every story in the backlog be estimated in story points? If so, who provides these estimates.
• Alternatively, should story estimation be part of Sprint Planning?
• When do stories get broken into technical tasks and by whom?
• Do technical tasks get estimated in hours? If so, who provides these estimates?
• If stories and tasks are estimated in different units, with which do you measure velocity?

The answer to these questions in many cases is that you need to find what works for your team. Whilst this makes sense, it would be nice to hear what works for other teams.

Answer 1

In my experience, the following works well but it is not prescribed by either Agile or by Scrum:

• You can indeed estimate every story in the Product Backlog, other than Spikes, in Story Points. The Development Team provide the estimate as they are the ones that will be doing the work.
• Story estimation is usually a part of Product Backlog refinement or Sprint Planning
• User Stories usually get broken into tasks during Sprint Planning, and occasionally during Product Backlog refinement
• Tasks are often estimated in hours. The Development Team provide the estimates as they are the ones that will be doing the work
• User Stories are used to measure velocity, because Velocity is the number of Story Points that are "Done" within a Sprint

Answer 2

As far as I've experimented:

Grooming backlog meetings can be used to estimate the stories in story points. It's recommended to do it before the sprint planning, so that we don't need to focus on estimations anymore at this point (well, mostly).

Planning poker can be used to let developers estimate the stories. The product owner shouldn't estimate because The development team members need to make a commitment about how much functionality they will complete in the upcoming sprint.

Regarding splitting technical tasks, I'm afraid I'm still looking for answers myself.