Estimates

I'm not sure what you mean by "Sprint meeting". Scrum events include Sprint Review, Sprint Retrospective, and Sprint Planning Sessions, and Daily Scrums (standups).

Scrum requires an ongoing process of backlog refinement in which the items on the Product Backlog will be revised and estimated. This is sometimes referred to as Backlog Grooming.

This is in addition to the Sprint Review, the result of which is a revised Product Backlog. Estimation of items can occur at this point too, although it is in the context of preparing relevant items for Sprint Planning.

The Product Backlog contains items that are functionally described by the Scrum team, preferably with acceptance criteria.

During the Sprint Planning Meeting the development team challenge (I think it’s a fitting word in this case) the PO by asking crucial functional questions. Hopefully more information will occur and the acceptance criteria grows. Reminder at this point in time we’re not talking about the HOW part, purely the WHAT.

After that, the team starts estimate the items. This can be done in many ways but ‘Planning Poker’ is by far the most used technique. Keep in mind that the goal is not about being exact. Perhaps it sounds a bit depressing, but the chances of a team estimating incorrectly is MUCH bigger than estimating it right and that’s perfectly fine… Just trust the system. (see link)
In the end it’s not even about whether the team estimated the items correct or not, it’s about the information that has been transferred during these moments.

Yes Sprint Planning Meeting is an "official Scrum event", but as Ian said, a lot of Scrum teams also include Backlog Refinement Session (Grooming Sessions) in their Sprints.

If you want to know more about “trusting the system” please read my following blog:
http://relativecomplexitytheory.blogspot.nl

Cheers, Chee-Hong

Hi,

I meant to write Scrum planning meeting.
Thank you for your answers, they do clarify some things but i am stil not clear about the product backlog process/estimation for the first sprint.

For the very first sprint, we will have a product backlog with enough items to start the first sprint as input to the planning meeting. Then all of these items are estimated during the planing meeting and a number of items are selected to be developed in the comming sprint?

What if we have a large almost complete product backlog as input to the first planning meeting, should all of the items be estimated then or maybee just a subset?

Chee-Hong you write that the the items in the product backlog are described by the Scrum team, what do you mean by that?

Hi Kappers,

When we are talking about the first ever Sprint Planning Meeting there are usually the following scenario. (if I miss one due let me know)

Scenario 1:
- The Product Owner has a list of “all” the items that needs to be done to make this product supercool.
- You are working in traditional company where the scope and time are fixed.
- No Scrum support from your company. This project is like a PoC.
This is usually quite a confronting scenario for companies I believe, because what I usually do is set up a Sprint Planning Meeting with the Scrum team and start talking about ALL the items. The reason why I say that it’s quite confronting is because usually you’re in a crucial moment where the PO needs to be convinced that his/her initial ideas isn’t that complete as he/she thought it was. Because during the Sprint Planning Meeting the Development Team is going to focus every item and ask functional questions regarding certain scenario. The changes are quite big that the PO will give you an answer like “I haven’t thought about that yet, or this I need to discuss, no idea” and that’s perfectly fine. It’s impossible to know exactly what you want, even though you think you do. But you are in a fixed scope/time project so you need to come up with a planning, so start estimating all the items BUT you make sure you return the feedback that some stories are still vague. They need to understand that it’s impossible to come up with an accurate planning while the items (requirements) are still vague.
If the PO can answer every questions, then fine, start estimating the items. After the Sprint Planning Meeting ask the team how much items they think they can include within the Sprint. What you can do is create subtasks for each items (stories) and assign ideal hours to it. Then simple let the team include x amount of items in the Sprint which they are comfortable to and voila, your first Sprint can Sprint. Based on how much items you take in your Sprint you can now come up with some kind of Agile planning.

Scenario 2:
- There is no Product Backlog.
- You are working in traditional company where the scope and time are fixed.
- No Scrum support from your company. This project is like a PoC.
The Product Backlog needs to be created. Set up a Refinement meeting or Sprint Planning Meeting and work together in creating the items. Sometimes the PO doesn’t have the items but only an idea so either he/she created a Product Backlog with items in it or the Development team assist him in that area. After that is done, continue with scenario 1.

Scenario 3:
- The Product Owner has a list of “all” the items that needs to be done to make this product supercool.
- You are working in Agile environment where one of the 2 variables (scope or time) are not fixed.
- Scrum support from your company.
This is where you want to be in. Set up a Sprint Planning Meeting and discuss just-enough items for the Development team to work on. It’s wise to discuss at least 2 a 3 Sprints ahead (if it’s possible of course) so that you discuss some longer term dependencies. Usually (if not, it needs to be!) the Backlog is priorities so start from the top and work your way down. If it’s an Agile organisation the first couple of items needs to be extremely detailed and when you go further down the stories gets vaguer and fuzzier. Don’t waste too much time on these stories for now. Instead set up a weekly Backlog Grooming session to talk about these fuzzy stories and try to break it up.

Scenario 4:
- No Product Backlog.
- You are working in Agile environment where one of the 2 variables (scope or time) are not fixed.
- Scrum support from your company.
Set up a meeting (grooming session or Sprint Planning Meeting) and try to create the items for the backlog. Again, preferably enough for 1 a 3 Sprints. After that, continue with scenario 3.
----
“The Product Backlog contains items that are functionally described by the Scrum team, preferably with acceptance criteria”

The Product Backlog should contain “functional requirements”. Most Scrum team uses the User Story format but that’s not mandatory of course. The PO is owner of the Product Backlog but that doesn’t mean he/she needs to create these items. The items can be create with help of the whole team. (Scrum Team)
I hope this helps!
Cheers, Chee-Hong

Thank you Chee-Hong!
As I understand you depending on scenario you take different actions, they all seem good to me. Really great answer to my question.

However when I try to figure out when the team should estimate the backlog items according to the Scrum Guide I can’t find an answer on that. For example it states that the product backlog is input to the planning meeting, it also states that the product backlog contains estimates. This would mean that the estimates should be done before the planning meeting?

However I guess this is up to the scrum master based on different scenarios when the estimation takes place.

The guide says "Product Backlog refinement is the act of adding detail, estimates" and that it is a ongoing process, which supports my theory that it is up to the scrum master when the estimation actually takes place?

However when I try to figure out when the team should estimate the backlog items according to the Scrum Guide I can’t find an answer on that. For example it states that the product backlog is input to the planning meeting, it also states that the product backlog contains estimates. This would mean that the estimates should be done before the planning meeting?

I don’t think you should interpret the Scrum guide like that. What is described in the guide is like in different stages.
Obviously the very first Product Backlog consists of Product Backlog Items, prioritised, not estimated and serves as input for the Sprint Planning Meeting. During the Sprint Planning Meeting, the team starts estimate the items one by one.
What is state in the guide as “the product backlog contains estimate” that is true, BUT at a certain point in time…

However I guess this is up to the scrum master based on different scenarios when the estimation takes place.

Theoretically it's not up the Scrum Master to decide when the estimate is done. Estimating is a part that is embedded in the Scrum process. (either during the Sprint Planning Meeting or Refinement session) Yes the Scrum Master can initiate these meetings, but theoretically it’s the PO responsibility. I like to emphasis this part because that’s something that’s not according to the Scrum guide. Personally I don’t believe the PO should or can always be responsible for the “project management” part. Basically what the theory tell us is “it is the PO’s product (and money) so it’s his/her responsible to monitor (manage) the project. I believe, depending on the organisation and type of PO, the Scrum Master can also be responsible for this part. But again, I don’t always apply this thought…

The guide says "Product Backlog refinement is the act of adding detail, estimates" and that it is a ongoing process, which supports my theory that it is up to the scrum master when the estimation actually takes place?

The Backlog Refinement session is indeed an act of adding details, estimations etc. Please note that this is an ongoing process so in another words, include it in your weekly even by (for example) sending weekly invites for these sessions. Either the Scrum Master or PO can initiate these sessions.
Scrum Master because he is the guardian of the Scrum process.
PO because it is his/her product and a refinement session can certainly help the PO refine his items. Perhaps also re-prioritise and/or re-estimate the items.

This will all affect the overall planning which is again very crucial for the client.

Thank you. Its clear to me now! Really good answers to my questions.

Hi Chee-Hong Hsia,

Thankyou for your explanantion. 

Let's say that we are speaking about value point espimating (similarly to story point). 

is value point also refined or reestimated during refinement sessions? 

Is the Developpment team responsible to do this estimate since the Product Owner is the most suitable person to unveil the value of items ? 

Regards!