Why is estimation done in the first part

Hi Rossi,

I'm not entirely sure what you mean with "always estimate at the first part".

Ideally the team should have approx. 80% of the PBI's estimated before starting a first sprint. Yes, start up can be quite time consuming, but there are ways to provide quick high level estimations.

Once the team has reached the 80%, the next step is to see how much work can be committed within an sprint.
Some teams also provide estimation in the second part of a SPM but that's more on tasks level, so don't confuse this with story level estimation.

Hope this helps,

Cheers. Chee-Hong

Hi,
Actually in the new Scrum Guide the planning is not necessarily splitted into part one and part two any more.
So you can estimate, break down and adjust the estimation story by story if this is helpful for you.
If you decide to split it, the first part will be about what can be done in the sprint. How do you decide, if you don't have estimations?
Best, Ludwig

> Why is the estimation done in the first part of the sprint plannning meeting and not in the second part?

There is no prescription in the Scrum Framework for when estimation must be done. There's a poor convention across the industry that estimation of story points happens in Sprint Planning. This is an anti-pattern, because each item on a Product Backlog must have a description, order, estimate, and value. Constraining estimation to Sprint Backlog items during Sprint Planning is inappropriate as it will leave the Product Backlog unsized and malformed.

It therefore makes sense to provide estimates as soon as items are admitted onto the Product Backlog. This means that backlog refinement - an ongoing activity rather than an event - is the best time to provide estimates. In fact the Scrum Guide makes it clear that Product Backlog refinement is an "ongoing process" in which "detail, estimates, and order" are given to the constituent items.

Posted By Ian Mitchell on 27 Feb 2014 03:48 AM
> Why is the estimation done in the first part of the sprint plannning meeting and not in the second part?

There is no prescription in the Scrum Framework for when estimation must be done. There's a poor convention across the industry that estimation of story points happens in Sprint Planning. This is an anti-pattern, because each item on a Product Backlog must have a description, order, estimate, and value. Constraining estimation to Sprint Backlog items during Sprint Planning is inappropriate as it will leave the Product Backlog unsized and malformed.

It therefore makes sense to provide estimates as soon as items are admitted onto the Product Backlog. This means that backlog refinement - an ongoing activity rather than an event - is the best time to provide estimates. In fact the Scrum Guide makes it clear that Product Backlog refinement is an "ongoing process" in which "detail, estimates, and order" are given to the constituent items.

I never thought of it like this. So if I'm not mistaken:

1. Before the sprint (during a refinement session) estimate approx. 80% of the PBI's.
2. During sprint planning meeting, discuss how many PBI's can be taken into the sprint.
3 Talk about the implementation.
4. Sprint.
5. Refinement session to talk about the upcoming items.

THanks guys

It therefore makes sense to provide estimates as soon as items are admitted onto the Product Backlog. This means that backlog refinement - an ongoing activity rather than an event - is the best time to provide estimates. In fact the Scrum Guide makes it clear that Product Backlog refinement is an "ongoing process" in which "detail, estimates, and order" are given to the constituent items.

Ian I agree with you in which the estimation happens during the work with the Product Backlog, in Refinement concretly. But...What happen in the Sprint 1? Probably in the Planning of this Sprint you only has a product idea.

There are no preconditions regarding how evolved a Product Backlog must be in order for Sprinting to commence. It is possible there may only be the idea you refer to and no backlog at all. In that situation, a team may use the first Sprint Planning session to plan just enough work to meet a viable Goal for that first Sprint. Estimation may involve an overall sense of achievability where there is no established velocity or throughput to refer to. Refinement of further work will commence from that point. WIP should be limited in order to improve the team’s sense of item size, and this experience fed into refinement sessions as soon as possible.

The way I was taught is that user-stories should be "refined" and meet the definition of "Ready" BEFORE Sprint Planning begins.

The purpose of Sprint Planning should not to be discussing what a user-story is about or how many points it gets, but rather to discuss which of the "Ready" user-stories can be placed into the current sprint and worked to a state of "Done" by the end of the sprint.

My philosophy lines up with @Ian's suggestions.  We estimate stories during refinement.  That helps to wrap up and show agreement from the team that they understand the story enough to start working on it.  We attempt to have enough stories estimated in the backlog to do 2 sprints.  That prepares for needing to adjust the sprint based on new information or if we ever have to cancel a sprint. 

Having said that, if we get to planning and find that something has been introduced to the backlog that is highly ordered or that the team has uncovered as being needed before stories already prepared can be worked, then we will point it on the spot.  But that is usually outside the norm.

Remember that estimates are just that.  They aren't necessarily supposed to be completely accurate.  It should be done based on the information you have available.  What you originally discussed seems more like trying to justify their velocity instead of just letting the velocity organically come to a consistent level.