Episode 4: 4 out of 5
The Sprint Planning should get you closer to the answer of what and how things will be done during the next sprint.
I intentionally did not write that it will give you the answer, because I believe that:
• the decision process of what will be done in the next sprint, in practice usually starts way before the sprint planning itself, during ongoing backlog refinement and refinement sessions
• the decision process of how the Product Increment will be delivered usually continues after the sprint planning, throughout the sprint as the team works on their sprint backlog items
Nevertheless, this event should allow to define the goal of the sprint – where the team focus should be throughout the entire cadence. Shaping the sprint backlog with estimated user stories, spikes and bugs is one thing; remember about the “how” part by following through to the task break-down, where the dev team deep dives into the stories and continues planning on an even more granular level. While technically this should be done during the sprint planning event, I’ve found mature teams conducting the break down further into the sprint (about 50-60% upfront, 20-30% in the first days of the sprint, the rest later on). This worked for them quite well, but then again, they were mature enough to identify & introduce this as an improvement.
The Sprint Review is the main event for conducting inspection of the up-to-date product. The great thing is that this can be done is so many various ways: presentations, open fairs, discussion boards. They key factors are to always remember about demo and feedback. Sure, it is important to have a summary of the sprint for everyone to understand what has been accomplished, what has not and why (although usually the team is well aware of that). However, the biggest value is brought from the actual working demo – this is the product increment that could be going to production! Inspect it! The second biggest value is stakeholder feedback. This is crucial for the whole team to get a sense of ownership, sense of value that they delivered and a comprehensive direction to where the product is heading. I always encourage the Product Owners to invite stakeholders to the reviews – there’s no better way to get or give feedback.
The Sprint Retrospective is to me, definitely one of the most important events. I can already say, that this is something I could not do without. Everything that is done by the scrum team, everything that is delivered and how it is done, with what quality, as well as how the teams work to approach issues that they stumble upon is an outcome of the team and its surrounding ecosystem. The team knows a lot regarding what makes them do well and what holds them back; and what better way to make them grow, than giving them an opportunity to improve on how they collaborate? The Sprint Retrospective is a chance to learn a lot about the team, help them improve their work and have fun, while building an amazing team atmosphere; yes! the “retro” is also a great time to let the team bond – when done properly – having plenty of fun. A colleague of mine, that I used to work with, showed me a great tool for getting ideas for an awesome retrospective: retromat.org – I can honestly recommend this. While I am currently preparing multiple ideas for my own retros, I often go back to this source to look for inspirations.
The Daily Scrum is about low-level day to day inspection and planning of the work being done by the team. It is about sharing how the team is progressing towards the sprint goal, taking into account any lessons learned and identifying how to overcome impediments on the way to reaching that goal. The “daily” is a 15 minute time-boxed event, but it can happen especially for new teams to exceed that time – this is a chance for the Scrum Master to step in and support them in sticking to the agreed time. Exceeding the time-box can also be a decision of the (mature) team; if they find it valuable then there’s no point in proving them wrong… It can also go the other way. I had the pleasure of working with a team, which decided to reduce the daily to every other day. We gave it a try and… after some time went back to having daily dailies. But this does not necessarily have to end in such way, as it is quite common for very mature, co-located teams to even resign from having any dailies at all, because they are just so proficiently communicative at all times and so organized that this event would just be a distraction to their way of working.
The Sprint is the fundamental time-boxed Scrum event, where the actual work happens. I’ve recently participated in a conference, where Jurgen de Smet elaborated on how the Sprint is where all the learnings from the previous events should be incorporated – and I find that just spot on! Considering that the other events mentioned above, enable learning at various levels as part of the three pillars (Transparency, Inspection & Adaptation) – the Sprint is where all the gained knowledge should be used to make the outcome as accurate, valuable and complete as possible. As specified in the Scrum Guide, the Sprint should last no longer than 1 month and allow producing a potentially releasable product increment. In my experience, the chosen length of the sprint should take the following factors into consideration:
• Product complexity
• Team setup (scaled)
• Product backlog stability (changing market / requirements dynamics)
The more complex the product, the more difficult it could be to build an increment in a short 1 or 2-week sprint. The more teams (in a scaled approach), the more time can be consumed by overhead to sync them, impacting how much of actual time is left in the sprint. Last but not least, the changing market demand – it always has impact on the product, having the Product Owner react to it accordingly. If the sprint is too long, the new discoveries may occur not as often as they should in order to maximize the product value. Just to give you a personal example, in a very large telco project with multiple teams, I have found three-week sprints to be optimal in balancing the managed overhead resulting from the project size and accounting for the product complexity (including changing requirements).
So which event would you eliminate? My bet goes with either the Daily Scrum or... the Sprint Planning. I think that I have already justified the idea behind eliminating Daily Scrum, but why the Sprint Planning? Well, having a mature and experienced team makes it quite common to start planning ahead in a 2-3 sprint range with good accuracy. Simple as that. Making the most of backlog refinement during the sprint, lets the team have an outline ahead of time, which they only confirm during the planning event. They can also react to changes to that plan instantly, as part of an ongoing process. Of course, I am far from recommending skipping any Scrum events. Especially for new teams it is crucial to follow the rules, because some smart people gave them a lot of thought – and it seems, that is the wise thing to do, when not knowing better.