mcsolid 2 days ago

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).

2
muzani 1 day ago

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 2 days ago

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

Sounds like normal career in development to me.