I hate scrum. But don't get me wrong on that - I think there are some ideas in it that do make sense. But my issue is that in reality it is doomed to fail.
The idea of having a certain amount of time that you can fill with exactly the right amount of tasks that are all so well defined that you can work on them without running into any issues when the sprint starts and that you can work on without interruptions and without new tasks suddenly popping up that have a higher priority is a utopia for any kind of software that is released and used by people.
And having dedicated time for the whole team to determine the complexity of tickets before the sprint starts, daily sync on what post-its you moved the day before and a sprint review at the end of each sprint seems like a huge waste of times in my experience.
How it normally goes is that nobody is prepared for the planning meeting so you spend a lot of time trying to understand what the tickets are about with the certainty that there will be edge cases that weren't considered by the person who came up with the ticket and that will make the development more complex than estimated in that meeting. And because this meeting often falls into the end of the last sprint when stuff is not released yet, everybody just wants to get back to fix open bugs that need to be fixed to keep the release date - and at the end, releases get delayed, stuff gets moved to next sprints and frustration builds up.
That's not true for the company you're working for? You're always on time for releases and get well-defined tickets? Good for you. For most of us, this isn't the case.
I might focus on processes we tried to overcome this in a different article. But this one is actually about the only part of Scrum that's fun: Retrospectives.
Retrospectives
For me personally, I like to see retrospectives as some kind of therapy session: You get all stakeholders that were involved in your projects since the last retrospective on one table and get a chance to talk about whatever is needed. May it be issues with the current processes, communication issues or personal conflicts.
With my team at Zageno, we usually have a retrospective every two weeks for around 1,5 hours depending on how many topics need to be addressed.
Review actionable items
At the beginning of each retro, we discuss the actionable items we agreed on in the last one (more about actionable items later) and discuss if the points we decided to improve (more about that later as well) were improved within the last two weeks.
Collect things to keep and things to improve
After that initial review, we use 5 minutes in silence for everyone to write down things that happened in the last two weeks that they would like to keep/that went well on green post-its and things that need to improve on blue post-its. After the 5 minutes, we go around the table and each person gets time to present there points and put them on the wall (ideally grouping similar post-its to those from previous persons). This is not the time yet to discuss those topics (a mistake I do to often) but it's only about collecting them and figuring out topics. A topic can be based on a group of post-its or if there are no similar ones, consist of only one post-it.
Prioritizing topics
With the topics on the wall, each member gets a pen and is allowed to draw 3 points. It can be three points on a single topic or spread across all of them. When everybody is done with this we sort them by the number of points/priority. Then we start discussing them one by one as extensively as needed until time runs out.
You could set a limit of X minutes for each topic if your focus is rather of discussing topics in width instead of depth.
Defining follow ups
At the end of the meeting the topics get collected (grouped by "keep" and "improve") and actionable items get defined based on the outcome of the discussions upfront. Ideally, the actionable items should be doable until the next retrospective - whatever it might be.
