Five Questions Scrum Masters Should Be Able to Answer

The Scrum Guide tells us what to do but not why. Nor does it tell what not to do. As agile professionals, we often get challenging questions from both Scrum teams and stakeholders. The response: "Well it is quite clearly stated in the Scrum Guide," may leave some unimpressed. This article looks at some of the common tough questions and how a deeper understanding of agility is necessary to respond to them.

Why do we all have to attend sprint planning?

It's a fair enough question. In more traditional projects, the planning would be owned by the project manager (who would consult key stakeholders and dev leads to build the plan). So why are 10 people doing what one could do? The Scrum Guide time boxes the sprint planning at max eight hours. So, for a team containing eight developers, this would mean 64 person-hours, spent on planning, that could otherwise be used for coding and testing, every month.

My previous Scrum team initially saw the sprint planning as a waste of valuable coding time. So I worked with the product owner to minimise the duration of these sessions and rush through the items. A few weeks later, I received feedback in the retrospective that they would like to get a better understanding of the stories before starting to code them. So I reworked the sprint planning, doubled its time-box, discussed with the product owner how we could give a more thorough walk-through of each story, and encouraged the developers to ask questions and seek clarifications. Rather than wasting coding time, our velocity increased.

This approach is also backed up by the Scrum Guide which states that during sprint planning, "The Scrum team may refine these items ... which increases understanding and confidence."

The second compelling reason for the entire team to attend sprint planning is that it helps the team to understand why they are doing it and not just what they are doing. The first activity in the sprint planning is to define the sprint goal. In his 2014 book, Jeff Sutherland talks about great teams being transcendent, meaning that they are aligned to a common goal and have a purpose beyond the individual. He talks about how small teams can become almost magical when aligned to a common goal. This is a million miles away from the old days of coding being outsourced to armies of developers who had no idea about what they were building or why. The sprint goal is the why; It inspires the team.

To learn more, Scrum Alliance members should check out the Learning Journey course on sprint goals. You’ll find out how a scrum master can support the product owner in this regard, learn how to say “no” when necessary, and so much more. Plus, you’ll earn an SEU upon completion!

Why do we have to do retrospectives?

As with the sprint planning event, some developers see the retrospective as a three-hour time box that could be better used for coding or testing.

The concept of Kaizen (normally translated from the Japanese as continuous improvement) has its roots in Japanese manufacturing in the post-war years. The idea was, rather than introducing new processes, to incrementally improve and fine-tune existing processing to deliver ever better quality and productivity.

Kaizen is one of the concepts that has strongly influenced agile principles and practices. One of the principles of the Agile Manifesto is: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.”

The three pillars of Scrum are: transparency, inspection, and adaptation. So, Scrum teams should be open and honest about what they are doing, reflect and discuss how they could do it better and accordingly make changes to their processes and practices. Hence, a retrospective.

I remember while working as a traditional project manager, I would diligently do my lessons learned with the team at the end of each project. We would earnestly gather and document some 50 or so items around how we could have done things better. The list would be carefully placed into a project archive never to see the light of day again. And I have to confess when starting new projects, I never once dived into a project archive to see what I could learn from their lessons learned. It never even occurred to me.

The retrospective is a similar type of activity to lessons learned but is a billion times more effective because it occurs throughout the project, at the end of each sprint. Each item is actionable and can be brought into the following sprint planning to improve an aspect of the team's working.

My previous Scrum team was less than enthusiastic about spending time sitting in retrospectives, but as they began to see that as their voices were heard and that things causing them pain were being addressed, attitudes changed. They even started reminding me if I had forgotten to schedule the retrospective.

Why do we have to deliver a valuable, usable increment each sprint?

"Hello and welcome to sprint five planning. Well let's just carry on doing what we were doing in sprint four shall we? I am sure there is plenty to keep us all busy.” Sadly, this scenario is not uncommon in teams supposedly practicing Scrum. Apart from contradicting the Scrum Guide, there are other problems with this approach.

1. Velocity is measured according to items done during the sprint. If nothing has been done, the velocity is zero — not a very helpful number to work with when planning the next sprint.

2. The Scrum Guide says each sprint is like a “short project” and for good reason.

3. Teams are generally motivated by delivering something of value to a looming deadline.

4. Teams are often dynamized and energised when coming towards a release. If nothing of value is delivered at the end of the sprint, the project is drifting dangerously toward a waterfall approach.

Delivering a valuable increment at the end of each sprint serves so many purposes. As mentioned above, it helps to drive motivation and create a sense of achievement while inspiring confidence from the stakeholders as they can see something tangible being delivered. It serves as a learning experience for the Scrum team. If they have deviated from stakeholder requirements, they can do some course-correction early in the project. Misunderstandings can be addressed, and the increment can help the stakeholders to visualise and clarify future requirements.

Why is a product owner different from a business analyst?

Again, a reasonable question as both a business analyst (BA) and product owner (PO) share many key skills. Both have a strong understanding of a product's functionality, how it delivers value to its users, how to understand, document and explain requirements, and how to spot contradictions and dependencies in requirements. But the BA is more of a listening role, and the PO is more of a decision-making role. The Scrum Guide states: "For Product Owners to succeed, the entire organization must respect their decisions."

In my experience, it is rare to find an organisation that is prepared to empower a PO with this level of decision-making authority. POs are often playing the role of BA within Scrum teams. The problem occurs when conducting internal Scrum activities such as backlog refinement or sprint planning where questions about requirements are raised. If the PO is playing the role of BA, he or she may have to go back to the stakeholders to get answers. An activity that could have taken minutes ends up taking days.

The role of the PO is critical to the success of Scrum and one that needs very careful consideration in any agile transformation.

Why can't we plan out the scope of sprints in advance?

At first glance, this might seem like a reasonable request and there are certainly plenty of so-called agile teams doing this. Having some idea of delivery dates for scope items could give a heads-up to change management teams, end-users, senior management and other dependent projects. The Scrum Guide does not specifically prohibit this, but it doesn't talk about doing it either. The Scrum Guide defines the sprint planning as the first event in a sprint. It is a planning event for the upcoming sprint and not for future sprints.

The problem with defining the scope of future sprints is that the plans can easily become commitments which, in turn, can become deadlines and before we know it, we have a roadmap with delivery milestones. We are doing a traditional waterfall project.

Secondly, one of the key benefits of agile projects is that as business models, markets, and technologies change. This is also true for the scope of the project. As the Manifesto for Agile Software Development states, we can "Welcome changing requirements, even late in development." So, with agile projects, we have a much better chance of getting a product that the stakeholders want now, not what they wanted a year ago.

So, what happens if we have planned out the scope of our future sprints, commitments have been given to stakeholders, and then we get a change to requirements? We may have to go through some form of change control process assessing the impact and costing out the change. We would be doing a waterfall approach.

Clearly the true spirit of agility is to only plan out one sprint at a time. Anything else reduces agility and leads us back to a waterfall approach.

I am always grateful to team members and stakeholders for challenging me and asking the tough questions. I believe these questions provide us with a very valuable motivation to increase our depth of knowledge of the agile frameworks.

Related Article: How to Engage Team Members in Scrum Events

About the Author
Adrian Baker’s first degree is in Philosophy so he’s always been fascinated by questions such as, “How can we do things better, how can we work better and organise ourselves better, how can we reach our true potential?” That’s why he believes agile holds some answers. Adrian currently works as a Scrum Master and Agile Coach with DBS bank in Singapore and has brought agility to many other companies such Cisco Systems, UOB Bank and Automation Anywhere.