[muzani]

I find 1 week ideal without the overhead.

Remove unnecessary demos or retros. You need the feedback cycle but often 1-3 months is fine, and 2 weeks is only useful for a beginner team.

You do need planning, context, and meetings to discuss the context. We moved these to two days a week where anyone is free to interrupt anyone else and call for a call right now. Nobody expects to be in flow on these days. But as we got better at teamwork, we only needed 0 or 1 days.

We do have 1 week sprints but it's about 90 minutes of sprint related meetings/week on average and that includes stand ups, retros and demos.

Work estimation into the schedule. They're called spikes. Time box them. No commitment is made without the confidence of the spikes. If you don't have confidence by the end of the spike, then something is wrong - the requirements is unclear, code is too opaque, you don't have the data, someone isn't cooperating, etc. These are all very valid outcomes of a spike. Maybe you need to call someone. Maybe you need to refactor.

[mcsolid]

Saying this probably indicates more problems but they also insist on demos each week and demos/retros every 2 weeks. Also they want metrics/retros to track team velocity.

How much time per week do you have dedicated to sprint meetings? Another issue we have is requirements are always lacking because it’s always fires (and everything is P1).

[muzani]

The most efficient form I've seen is one 30 min meeting to discuss what we plan to do and what went wrong/well with previous plans. And a second 60 min meeting at the end of the week to show what we've done, the impact, and the GTM plan.

But if you have frequent P1 fires, then you definitely need the retros quite often. In our case, we always do post mortems for a P1. We dig deep into root causes and this alone is a significant meeting. If it's P1, then, well, it should take everyone's attention. If it's not that major, then it should be some other level. But they shouldn't be happening more than one a quarter or something. It's okay to not be adding features – sometimes reducing fires is significant progress, lol.

Sprint planning meetings for us is just 30 min. We update a doc, it doubles as the retro. Most of the tickets and stuff is already managed by Jira; PM just ticks what we plan to do that sprint. Requirements have already been reviewed before the meeting starts, the meeting is where we work out a plan for it.

[jf22]

Useless metrics, lacking requirements, tons of P1s and emergencies...

Sounds like normal career in development to me.

[thiht]

> Remove unnecessary demos or retros

Remove the 2 most important meetings in a functioning team?

[muzani]

If it's important to you, then keep it, of course. Every team is different just like all code is different.

The symptoms of too many meetings is people don't attend them, work during them, complain about not getting things done, etc. If the retros are working, you shouldn't need many of them. If they're not (which sounds like OP's case), then they should be less frequent.

Demos tend to be redundant. Most of the teams I worked with know exactly what the team just built; sometimes the CEO is QA. In the bigger teams, the stakeholders might be juggling too many things to attend anyway.