“The product backlog items are too big for one sprint”

Remember that the PBIs are not the core thing in Scrum, its the Sprint Goal, which is a stepping stone to the Product Goal.

It’s not some random bundle of functionality, or a set of requirements, it’s an experiment to explore product-market fit.

“Not possible to make them smaller”
What’s the barrier to making them smaller?

Are you using Jeff Patton’s approach to user story mapping?
Do you apply all of the story-slicing patterns?
Does the architecture need to be reworked?
Maybe try a “magic wand” retro or an Ishikakwa fishbone exercise on this?

“Recommend Scrum with Kanban”

If you are not doing product innovation I’d always suggest this, but NOT as a way of getting out of having Sprint Goals, a Product Goal and a roadmap.

The only exception there might be a compliance project where the requirements are known and you are implementing “policy as code”

But – Kanban won’t help you split the items smaller, and you still need to do that….

I’m not a fan of formal interview questions. At a point it’s like setting an examination, and you tend to be testing their interview technique as much as their actual suitability.

Can people bluff their way through an interview by saying the “right” thing, when in practice they would do the “easy but wrong” thing? There are dozens of people out there offering “Scrum Master interview coaching” and saying “fake it until you make it”

That said, some good conversation starters tend to be

– Think back to the worst mistake you have made – personal or professional – that you are prepared to share with us. Tell us what happened, how you addressed the outcomes, and what you learned as a result?

– Tell me about your worst retrospective.

– What tends to be the biggest challenge you have come across in support the growth of an agile workplace, and what approaches have you tried?

– What agile books, articles, posts or podcast have recently had an impact on you?

I think whatever works for you; what I tend to go with is seeing the Sprint Goal as something we approach iteratively and by negotiation in planning. Which means:

– the PO has a proposed Goal and some Product Backlog Items to meet it
– those PBIs have been refined including the team so it’s not a surprise
– the team inspect and adapt – maybe taking some things out of a PBI, if they are not needed
– the Sprint Goal might also get modified in this process

That said, to me the key thing is not *how* you come up with the Sprint Goal, but that it actually matches the outcomes we want

– it clearly communicates to everyone why that Sprint is valuable
– it is a stepping stone towards the overall Product Goal

That is to say it’s connecting the work done in the Sprint to the overall *strategic* direction your Product is taking, and why. That implies (for a start) that you have a product strategy.

Even better if you are *quantifying* the value and saying how it will be measured; then you have a real target that facilitates further inspection and adaption of the Sprint Plan as you go.

In terms of quantifying, I use the 7 benefits (if I can)

– saves time (ie faster customer outcome)
– saves money (reduces customer costs)
– makes money (increases customer revenue)
– increased durability (extending product/asset lifetime)
– comfort or convenience (reduces waste-of-motion)
– increased safety or reduced (business) risk
– ego/prestige increase (brand value, investment of time/money by others)

That means a goal that is expressed as feature, advantage, benefit:

We added X, which uses technology Y, to produced outcome Z…