Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

Estimation & Planning

Last post 01:58 am June 21, 2014 by VS Chandra Mouli Silaboyina
7 replies
03:02 am June 13, 2014

Hi All,

I've seen in some scrum practicing teams performing sprint planning without having backlog grooming. i.e Stories are not being estimated with story point. They are directly taking the story based on importance and asking team how many hours required to complete the story and what are sub-tasks. I strongly feel its not correct. most of the time the stories are customer defects and require research and analysis. I can say they are mixing the estimation and planning or bypassing estimation.

Estimation should never mix with planning.Please share your thoughts on this.

My understanding is a sprint planning meeting should have the following things to do:

1. Calculate the team capacity
2. Sprint Goal
3. pick the stories based on capacity
4. Task breakdown.


03:21 am June 13, 2014

Scrum doesn't forbid making estimations during Sprint Planning. I would say this is usually the last point in time it can be done before actual work on the Sprint starts. Some teams in fact don't do any estimations at all. They are able to cut the PBIs of the equal size and estimation becomes reduntant. Some teams are able to do Sprint Planning so effectively that they don't need PBRs at all.

Imagine a situation that after Sprint Review the Product Backlog is updated and PO decided to insert a new feature at the top of it. You don't have any time for PBR before the Sprint Planning.

Capacity can be calculated as you wrote but is also can be thought of as a "gut feeling" of the team. It's not mandatory to be calculated in ours.
Scrum doesn't prescribe using stories. It's just a good practice.

There's no "correct" way of doing Sprint Planning. What you're talking about is just some practices. Some can be appropriate for the DT, some not. Follow the Scrum Guide defininion of the Sprint Planning.

05:21 am June 13, 2014

> most of the time the stories are customer defects and require research and analysis

If that is the case, would you say you have clear Sprint Goals? Remember that the goal is the purpose of the Sprint, and estimates are a means of determining how much work the Development Team can take on.

As Illya says, some teams cut the PBI's to be of roughly equal size. That can be a viable research & analysis technique in its own right.

06:22 am June 13, 2014

I agree with Illya as far as the PO's perspective is concerned. For me as a PO, I am responsible for the Backlog and wnat to have estimates as soon as possible on the one hand, but do also not want to disrupt during Sprints on the other hand.
That is why we sometimes do estimations during Planning.

11:28 am June 13, 2014

Estimates in the backlog serve two purposes:

1) to determine priority. Since it is the PO's job to maximize ROI, he will need Effort vs Value in order to make a judgement on priority. The ROI calculation can be done at the epic level or story level depending on the needs of business.

2) to do release planning. effort estimates in the product backlog in conjunction with velocity will provide a projection on future release(s).

So long as the PO is able to maximize ROI and appropriately plan releases for the business needs, how and when estimation is done becomes a irrelevant.

11:51 am June 15, 2014

For me, estimate is useful to convey the conversation among users / PO / dev team.
The point is not about having "accurate" estimate, (is this PBI 3 or 5 points, and this one 8 or 5 ?) but having a good understanding of the PBI.
It should be done before the Sprint Planning Meeting, in order to have enough time to discuss the 2 topics (what & how) & craft the sprint goal.
If this is not done before the Sprint Planning Meeting, most of the time is spent one the estimates, and the "how" and the sprint goal are just skimmed.

01:37 pm June 18, 2014


What your team is doing does not violate Scrum, but they may be using practices that are suboptimal. So, while your team may be using the Scrum framework correctly, they have not yet optimized how they *implement* Scrum, or "fulfill" the framework.

I'm a big believer in refinement (formerly called grooming), and my suggested practice is to get 2 sprints ahead on refinement.

More here:

01:58 am June 21, 2014

Thank you all for your precious suggestions and opinions

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.