Comment planifiez-vous et examinez-vous efficacement les sprints ?

The first thing to understand is that each Sprint is different, and if you try a cookie cutter approach with no adaptation to capacity, team and even squad mission, it will fail. Second: sprint goals need to be defined and agreed cross-functionally. Top down won't work. Third: using historic of the team should point the direction, but you should also consider outliers (vacations, possible issues, launch days, offsites) before defining on a Sprint goal. Last: the best sprint goals are "shipped software" or some form of progress creating user value.

This step does not make sense. You already have a Sprint Goal and you can pull in work gradually during the Sprint. The priority has already been decided by the Sprint Goal When you pull in work gradually you don't need to worry so much about capacity and availability.

Prioritisation of sprint backlog is ideally owned by a technical lead and not a PM. It demonstrated knowledge of the squads' mission, shows the PM can effectively communicate what matters for the company and for the Roadmap, and will allow the tech lead to be better informed as the backlog is groomed and tackled. This prioritisation should be done ahead of time, and when plannings, refinements or groomings happen, the team should already know why the backlog is sorted as it is, and how each item helps the team deliver on their goals.

Crafting the Sprint Goal is part of Sprint Planning. In the previous paragraphs there already is a Sprint Goal, so Sprint Planning already took place. Roles, responsibilities and expectations should be clear and there is no need to assign Sprint Backlog Items up-front.

The best Sprint plannings are driven by engineering, not PMs. Product Managers should join in order to bring context, show success, raise the ambition bar, and remove doubts or barriers. Every time a PM speaks in a planning that isn't around one of the above, it shows the engineering leaders aren't prepared enough. In this case, run pre-plannings where PM and TL can align themselves and do some prep work.

At the Daily Scrum a goal is set for the next 24h and we reflect on the progress toward the goal for the next 24h. That's what should be discussed, keep it simple.

The best way to track sprint progress is by running effective daily standups, having clear views of sprint burn charts on JIRA or Linear, and have the team be transparent about what is going according to plan and what is not. A complement would be to use DORA metrics to track overall performance, and understand how the sprint performed vs these metrics. This is the engineering team's job, not the Product Manager, though a PM should be available to help improve on the progress.

I strongly agree with Andre Albuquerque's viewpoint that "Daily stand-ups are essential and offer significant benefits when driven by the engineering team to enhance transparency and engage product managers for accelerated outcomes." However, the integrity of these rituals may suffer when they are commandeered by leadership driven by FOMO (Fear of Missing Out) or an insatiable desire to be present in every meeting.

Daily standups are not optional if you want an empowered team. The best standups are led by engineering, not product. PMs should also provide updates, not just listen. Most teams feel PMs are blackboxes, so use stand-ups to make your work more transparent, and show how you're laying foundations to help progress the Roadmap and get the team to success. It's also a great place to know how you (PM) can help accelerate the team.

I always start our retrospectives by reminding everyone to not make it personal, and don't take it personally! When everyone feels safe and comfortable sharing what did and didn't work, you can grow as a team very quickly.

Sprint reviews are incredibly important moments, alongside retrospectives, that most teams fail to run. The best sprint reviews include 1) Data on performance of the team (including delivered points or issues vs committed), 2) feedback from the team and customers, 3) wins and losses, 4) progress of the Roadmap, and 5) an overview of what is coming. It also helps define areas where next sprints can work better (like retros). Define an agenda, have a leader of the review (recommend rotating within the team) and make the action points clear by the end of the meeting.

In my experience, backlog refinement is an overlooked sprint ritual with a huge upside, especially in enterprises. Refinement reduces surprises and churn. Beyond providing clarity, regular refinement prevents backlog pile-up. Don't just do it once - make refinement an ongoing process.

You should also consider, as part of an efficient Sprint planning and review culture, the refinement of the backlog. It's important that as a PM, you can provide prior context for the planning, at the very least by discussing the structure of what is expected in the stories and beginning to address any questions or concerns regarding tasks for future Sprints