Scrum

It’s the last day of 2025 and, despite everything that happened work wise for me this year, I am coming out of 2025 very grateful. I have taken some time to write down a few reflections from the year.

• There has been a dwindling number of available roles for Agile practitioners such as Scrum Masters and Agile Coaches. Yet there is still a lot of work to be done, as long as there are teams that struggle to ship software consistently and many more teams operating as a feature factory with little clue about how much value they are delivering. What we need more of are agile practitioners with hands on product delivery experience who can help teams navigate the complexity of their work.

• There are still many practitioners who approach change by documenting “best practices” and then trying to force teams to comply. That is not going to work in the long run. What works better and actually sticks is involving people in co creating the change they want, and creating an environment where that is possible is one of the first steps to long lasting change.

• The marketing “rule of 7” from the 1930s suggests that people have to see an advert seven times before they buy. That principle still applies today. In practice, Product Owners need to share their Product Vision and Goals multiple times – maybe more than seven – before it really sticks, and even then these will eventually need to change. Try different formats: audio, video and text; the teams will get it over time.

• There continues to be widespread misinformation about Scrum and other agile frameworks, and the truth is that our clients do not care about the frameworks themselves. On a recent client engagement, I found that using terms different from Scrum’s official terminology helped us get started. It just means that, as a change agent, you have to define a delivery framework that is explicitly designed for your context.

• Velocity and “Say/Do” continue to be useless metrics. Better alternatives include flow metrics. In large organisations, I have found “Lead Time” – how long it takes from the conception of an idea to releasing features to users – particularly useful. It exposes organisational waste that cuts across multiple areas of the organisation, in ways that leaders might find interesting (or uncomfortable).

I spent the better part of 3 days last week in a Certified LESS practitioner course with the awesome Bas Vodde, one of the creators of the LESS framework. I had so many ah-ha moments, and this is my attempt to document some of the key learning moments for me over the course of the 3-day course. These are my notes, and there is a lot more context that might help you as a reader. However, as you read, feel free to reach out if you want me to provide more context about any of the notes here, and that might feature as a blog post in itself.

I often get attendees at our Scrum Training ask me for my preferred format for a Daily Scrum. I don’t know that I have a preferred format, but definitely not “What I did yesterday, what I plan to do today and discussion about Blockers”. However, if I can get you to reflect on the purpose of the Scrum Guide:

… to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.

A good format might be:

Most Teams that regularly run a Sprint Retrospective use the dreaded quadrant, What worked well, What Didn’t work Well, Ideas and Actions (and variants of this quadrants). I am sure your team has used this format many times. I coach Scrum Masters and their team to always prepare for Sprint Retrospective, and part of planning is observing the team all through the Sprint and experiment with different formats for running the Sprint Retrospective.

Increasingly, I encounter developers who don’t seem to enjoy using the Scrum Framework to deliver software, and this is a cause for concern because I have fond memories from my days as a developer working on a Scrum Team. I relished the collaborative atmosphere within the team, where everyone supported each other in development, testing, deployment, and held a shared sense of accountability.

However, nowadays, I hear developers express their discontent with Scrum for various reasons, including:

The Product Backlog Refinement session is not an official Scrum event, but it is a crucial activity that helps Scrum teams to achieve a shared understanding of the product backlog items in preparation for the sprint planning. Teams that adopt the product backlog refinement as a complimentary practice tend to have smoother sprint planning events. The number of refinement sessions within a sprint depends on various factors such as the state of the product backlog, the maturity of the product, the Scrum team’s availability and experience.

The commitments contained in the Scrum Artifacts are arguably one of the important element of the Scrum Framework; these commitments when deployed as per the intentions of the scrum framework contributes to increasing the effectiveness of the scrum team.

I was asked to help out a Scrum Team that did not see much value out of a well-crafted Sprint Goal for their Sprints. In the sprint planning, the team would rollover every product backlog item (PBI) that was not completed in the last sprint, and the team would add a few more PBIs from their backlog on the ask of the team manager, who also attended the Sprint Planning regularly. Evidence provided in their product backlog management tool showed that the team had not for once completed all the PBIs in their sprint backlog in the last 6 - 9 months.

Selecting a product backlog management tool can be a daunting task, as there are a plethora of options available on the market. Some of the most popular tools include Jira, Azure Dev Ops, Kanbanize, Trello, and Rally, to name a few.

As a Scrum Master, it’s important not to view yourself as an administrator for the chosen product backlog management tool, but rather to focus on understanding how the tool can support the Scrum team to be an effective team. This post is a guide on how the product management tool should support the Product Owner, Developers, and Scrum Master in executing their accountabilities as defined in the Scrum Guide.

Should agile teams estimate defects?

This a one question that teams often find themselves debate and my perspectives has changed over the years on this. The short answer is … it depends on your team context and what you are trying to achieve with estimation.

Estimation is a practice that helps Agile Teams forecast the effort that is required to get a task done e.g. deliver a feature and as such, it contributes to capacity planning for the team. This implies that would be impossible for a Scrum Team to forecast how much work it can complete within a sprint if the Product Backlog Items are not estimated.

Passing the PSM 1 assessment could be considered an indicator that you understand the Scrum theory and the principles that underpin Scrum. I always tell students in my PSM class, that my intention is not to make them pass PSM 1 but understand Scrum theory and principles.

There are a number of exercises that Professional Scrum Trainers invite students to partake in the course of the PSM 1 class; these exercises have been designed on practical experiences of Professional Scrum Masters and these exercises create a solid foundation for you as you commence your Scrum Master career.