(Copied from a lengthy Slack message and edited for this medium)

A thought came up in a team retro at our offsite meeting, and I think it is relevant to PM and team expectations in sprint planning, agility, etc. – several recent topics:

Some teams have the habit of using sprint planning mainly to estimate tickets and arrange them into multiple sprints. This promotes rigidity of plan and squanders the power of a sprint to deliver a slice of functionality.

I've witnessed this sort of problem before, and it comes in part from a misunderstanding of what a sprint is for (it’s not just a planning increment but a shipping and goal increment) and what it means to be agile.

The usual way agile sprinting is taught is that each sprint needs a goal – a local smaller goal that serves the customer and serves the larger goal of the project/enhancement/initiative. Stories should be selected to serve that goal. Other stories should remain in the backlog as we are likely to learn things during the sprint that will inform the goal of the next sprint. With the overarching goal in mind we should be able to select smaller sprint goals on a sprint-by-sprint basis and avoid rigid pre-planning.

It gets interesting when we have a dependency diagram, because, while that’s a sensible and useful document that describes what is blocked by whom, it can lead us to deliver in an order established via the dependency diagram (a technically-driven order) and have very little to show for our work until the final sprint. Proceeding in this way is rigid and developer-focused, not customer-focused. So the challenge falls to the team, and especially the trio, to select a sprint goal that they can deliver, even badly, working around dependency problems where they can. It's not easy, but it gets us away from the rigidity that over-planning creates.