I would like to know when the estimates are supposed to be produced.

Last time I was part of a Scrum team, I think we were providing initial estimates (that would then be quickly reviewed and confirmed or amended at the sprint planning) during some sessions called "story grooming sessions" which were randomly held all along the actual sprint (an hour here and hour there).

Can you guys confirm that's the general practice?

3 Answers 3


The official answer from the guide is:

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.

But yes, having a "grooming" or refinement meeting is regular practice. Whether they are held randomly or at fixed intervals is up to you, personally I prefer fixed intervals so the sprint can be planned better.

  • Aren't task estimations supposed to be completed before the beginning of a sprint?
    – embedc
    Commented Jun 9, 2019 at 8:02
  • @embedc For the backlog items that go into that sprint? Yes. But even for the others the estimation can take place before the actual planning meeting, so it's actually planning, not estimation. The PO will want to know what an item "costs" before making the final decision about it's priority. So it's good practice to have a few sprints worth of items estimated, so the PO can do their job properly and/or even go on vacation without a problem.
    – nvoigt
    Commented Jun 9, 2019 at 8:11

The idea is to have stories going in to a sprint estimated by the end of the sprint planning meeting.

However, that does not mean you have to do estimation during sprint planning. A lot of teams will do estimation during backlog refinement prior to sprint planning.

There is no 'best' time to do story estimating. It will depend on the team, the organisation and the domain.

It is worth considering the following though:

  • If you regularly struggle to get estimates done by the end of the planning meeting then it makes sense to do some estimates prior to that meeting.
  • If you do your estimates too far in advance then they may need to be re-estimated.
  • Estimates can help the Product Owner with prioritisation.
  • What determines the time intervals between the sprints? Tasks estimations?
    – embedc
    Commented Jun 9, 2019 at 8:04
  • What if estimations take quite a lot of time (because an investigation is required)? A sprint shouldn't start before the estimations are complete?
    – embedc
    Commented Jun 9, 2019 at 8:06
  • 1
    Sprints are fixed length (typically 2 weeks). If an investigation is required we do what is called a 'spike', which is a fixed length investigation task. A spike is brought in to a sprint in much the same was as requirements are, so the sprint starts in the normal way. Commented Jun 9, 2019 at 10:28
  • Thank you. Does it mean that the task will later be assigned to a person who investigated and estimated it (e.g. for the next sprint)?
    – embedc
    Commented Jun 9, 2019 at 13:38

Story estimates should take place during the Sprint Planning meeting, which has the Product Owner, Scrum Master, and the Product team.

You should also conduct regular Backlog grooming meeting, also referred to as backlog refinement or story time. It is a recurring event for agile product development teams. The primary purpose of a backlog grooming session is to ensure the next few sprints worth of user stories in the product backlog are prepared for sprint planning. Regular backlog grooming sessions also help ensure the right stories are prioritized and that the product backlog does not become a black hole.

The backlog grooming meeting is done to

  • Break down large user stories into smaller tasks.
  • Discuss user stories with the team, answer any related questions to smooth out any ambiguity.
  • Ensure upcoming user stories meet the team’s “definition of ready” by adding key contextual information and acceptance criteria.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.