PO way of preparing for the sprint planning - creating a fake sprint

Using this approach, how does the team craft a Sprint Goal?

Two things come to mind:

• What does the Development Team think of this approach?
• Why do you attribute this approach to under/over planning for the Sprint? Assuming that enough of the top of the Product Backlog is properly refined, why would isolating the top of the Product Backlog into a "Sprint" be any different than walking down the Product Backlog and reviewing those items and moving them into the Sprint?

is there any other situation where the product owner and the development team collaborate together to groom the top of the backlog prior to the sprint planning meeting? 

"Still I find that this has the effect that the team either commits to too much or to too little for the sprint, as removing SP/tickets does't have the same effect as really looking at each story and adding it to the SBL."

is the projected capacity of the development team used as an input to the planning meeting? 

are the PBI estimated? 

Do the Development Team consider that they are pulling work into their own Sprint Backlog?

Do they consider themselves able to provide a realistic forecast?

Is the Development Team accountable for the quality of its forecast?

I have no issue with the PO looking ahead. Whether that be maintaining a high level roadmap over the longer term or populating the next sprint or two with candidate items for more detailed shorter term plan. Greater transparency over the direction can only help. 

I also like everyone to be well prepared for sprint planning.  Everyone in the team should be well aware of what is coming next and be familiar with the backlog items that have been explored during an ongoing refinement and elaboration process.

Note I said candidate items.  Nothing is set in stone.  The dev team and the PO still need to agree the sprint goal and decide where to draw the line on backlog items during sprint planning.  

@Ian: this is a venture world and most of the projects are mostly prototypes w/o real customers. They are done and then the market is being probed for them or the new version. Hence there is seldom a simple/clearly defined spring goal, no matter how much I ask for it. 

Also the team works on two different projects with two POs. 

Why they commit to more? That is a good question! There are 5 POs and 3 teams.

It's just an observation, that the POs who use this approach somehow make the team commit to more work in a sprint. They sometimes do not succeed in finishing all the work, but since sprint fail is no longer a thing and there is no clearly set sprint goal, no one really feels accountable. 

That is another issue which I tackle differently, but for me this "take out work" approach somehow tricks the team into taking more work than the "take in" approach. 

And yes, there are BL grooming meetings where the BLI are refined, estimated, etc. Obviously not all of them make it to the fake sprint. And also the team does not really look at the fake sprint before planning, so "seeing what comes next" is not really a benefit. And my opinion on "looking ahead" is that it's counter productive and a not really fitting with an agile way of thinking. 

In my experience, many project owners prefer to create a "staging" sprint where they can move items in/out as they consider what their objective is for the next sprint, and what that might look like.   For them, it is easier and clearer to "stage" sprints than to work strictly through backlog prioritization.   It also provides the Development Team some transparency on what the PO is considering, which can help them prepare for Sprint Planning as well.

From the Scrum Guide:

The Product Owner discusses the objective that the Sprint should achieve and the Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal. 

To me, as long as the Product Owner can communicate this, it does not matter whether they use a "staging" construct or not.   I would not refer to it as a "fake" sprint though, as the word "fake" has negative connotations.

There are 5 POs and 3 teams... the POs who use this approach somehow make the team commit to more work in a sprint. 

Neither of these situations help Scrum adoption and practice.   There are inherently many issues with a team serving more than one Product Owner, and no one can ever "push" work to a Development Team in Scrum.   

The latter is a situation that should be addressed immediately - if there isn't respect for recognizing and working with Development Team capacity and ability, and if the Development Team is not allowed to make their own forecast of sprint work based on what is offered/discussed, then Scrum is not being practiced, unfortunately.

+1 Timothy

I agree that the real problems lie in "the team works on two different projects with two POs. Why they commit to more? (...) There are 5 POs and 3 teams. (...) the POs who use this approach somehow make the team commit to more work in a sprint." and NOT the "staging" sprint approach. The staging sprint approach works well in my company, is not against Scrum Guide if areas mentioned in this topic are properly addressed, but a team being unable to focus on 1 product is against Scrum. 

On the other hand in "team works on two different projects with two POs" you meant products, or projects? Both would be bad, but if 2 projects are in one product that it would be "different bad".

Hi,

'Staging' or 'fake' sprints were used in JIRA where I work, but I've urged my Product Owners to not use them anymore so that developers are pulling items into their sprint (not being told what to take) during sprint planning.

To help my PO's decide roughly what's next in their fake sprints, they simply put post it notes in a section on a wall to give them the focus they need.

Steve

There is an important artifact that gets created every sprint--an increment of a potentially shippable product. In my humble opinion, fake or not, I wouldn't refer to it as a "sprint" if there is no increment to deliver.

Regarding "committing" stories, it is normal for the dev team to over-estimate or under-estimate tasks that they put in the sprint backlog especially during the first few sprints. Scrum is based on empiricism. The team will mature based on experience. The accuracy of estimation and forecasting increases over time and inspecting and adapting often enough greatly helps. 

Cheers,

Harley