Of course, there are things that have to be improved: some Scrum events have been interpreted too lightly, while others have been given too much weight.
In particular, we have given too much space to refinement sessions, decomposing each story or each bug into individual tasks, sometimes even analyzing the source code. As the team grew, this process became increasingly long and complex, ending up taking time away from activities. Also, his overzealousness sometimes would prevent us from having enough analyzed and estimated items to make sprint planning useful.
In fact, we used to put the ready items into work, but often it happened that during the sprint the operation ended, so the following ones were fished from the backlog basing on their business value, but without any actual planning.
This made it difficult and unclear for stakeholders to understand what the development team was working on, thus affecting the transparency of the process.
Besides, we’d definitely overloaded the review phase: for each item we’d check the entire set of acceptance criteria with the Product Owner (PO), which, in addition to making the event long and tedious, left out all non-technical stakeholders, ie the most interested in knowing the new features rather than verifying their correct functioning.