When is the best moment to provide Product Owner with a sprint forecast?

Hi P.
The sprint goal and the forecast are two separate things.
The sprint goal is supposed to define the value the sprint is supposed to deliver. After doing the first part of sprint planning (forecast: What can be done), the team is able to estimate if the sprint goal is realistic. This sprint goal may not be changed during sprint (or else you can cancel the sprint). If you feel better with setting the sprint goal at the end of the planning, I see no problem with that, taking into account that you don't have to split the planning in two parts according to the Scrum Guide update from 2013.
The forecast is supposed to give the PO an idea how much can be accomplished of the planned work. As this is an estimation, usually the team will accomplish more or less than the forecast. However, this doesn't matter, as long as they meet the sprint goal. They can just renegotiate the forecast.
Best, Ludwig

> Isn’t it more logical to set up the Sprint Goal after the second part is done?

No, because the Sprint Goal should express the value to be delivered, and that should be decided by the end of the first part of Sprint Planning.

By the end of the second part, the Development Team should have a good idea of how much work they have actually taken on in order to achieve the agreed Sprint Goal. If there is too much or too little work then they should inform the PO of that fact. They can then replan the value to be delivered - and the work that will need to be done - so the intended goal can be satisfied.

Hi Ian,
I get your point. How do you do this if you don't split the planning? In the new Scrum Guide, the planning does not necessarily have two parts any more, it just has two subjects. In practice this means you can either pick all the stories and then create tasks for the stories as before, or you can pick the first story and create tasks for it and proceed with the next one. Would you define the sprint goal before the first story, in between or after the last one?

Hi P,

I fully understand what you mean. I get that question a lot from teams that are relatively new with scrum.

I think the most important thing to accept here (or in your case, to teach your team) is that nothing is guaranteed. Yes it may sound logical to first “workout” a couple of stories beforehand before giving a forecast/commitment, but this is nothing more than a false sense of security.

The reality is that during the sprint the team may (or may not) run into impediments and unplannable things like sudden sickness, overlooked criteria, technical difficulties etc. etc.

With all these unknown/unplannable factors, it’s way better to rely on your teams relative estimation and use this as an indicator to forecast the sprint and eventually craft the goal. Trying to get the items clear beforehand is a waterfall characteristic full of false securities and wastes which sounds logical but doesn’t work.

> How do you do this if you don't split the planning?

Good question. The revision to the Guide allows the interleaving of the two topics, much as you suggest. This potentially improves the emergence of a Sprint Goal and the planning of the work to achieve it.

Note however that the Guide predicates the second topic on "having set the Sprint Goal and selected the Product Backlog items for the Sprint". So there is still an element of before-and-after to the sequencing of the topics. Perhaps it begs the question: are the topics really not still Part One and Part Two after all?

Personally, I'd expect the Sprint Goal to be agreed once there were enough high-value user stories to comprise an MVP for the sprint. That's how I interpret the potential for emergence...but that is nothing more than my own take on this matter.

Posted By Ludwig on 18 Mar 2014 09:34 AM
Hi Ian,
I get your point. How do you do this if you don't split the planning? In the new Scrum Guide, the planning does not necessarily have two parts any more, it just has two subjects. In practice this means you can either pick all the stories and then create tasks for the stories as before, or you can pick the first story and create tasks for it and proceed with the next one. Would you define the sprint goal before the first story, in between or after the last one?

I would like my team to first forecast how many items they can include in the next sprint based on their average velocity. When that’s done the development team and PO come up with an awesome goal that basically sums up all the items together.
After that, I would like the team to think of a plan (usually subtasks) to meet Product Owners demand.