Notes on Scrum: Useful tips and reminders that I picked up from the Professional Scrum Master Training

Tags: Agile Team Scrum

Today,  I finished a two-day Professional Scrum Master Training program at Cap Gemini by Gunther Verheyen with my good friend and colleague Thiery Ketz. At our company (NowOnline), we've been migrating towards Scrum for a while now. But we appreciated the opportunity to cement our knowledge by getting certified, learn from more experienced scrum masters and pick up important details that we might have missed in our enthusiasm. Although the course did not teach me anything fundamentally new, it did give me a good number of pointers that I would like to share in this post. Hopefully, this can clarify some issues that other scrum masters, like me, have been struggling with when implementing Scrum that might not be addressed so specifically by the Guide. I will assume at least some basic knowledge of Scrum. If you wish to learn more about Scrum, take a look at the aforementioned Guide. In the near future, I intend to fully describe the Scrum process in a series of posts.

Thanks and a disclaimer 

Let me begin by thanking Gunther for the excellent training program. I expected a mostly theoretical course, but it was sprinkled with real-life examples, training sessions and team excercises. Gunther is also an excellent trainer in that he knows how to bring his knowledge with authority, give practical examples and deal with skeptical responses. So, if you're ever looking for a good Professional Scrum Master, Product Owner or Developer course, check out Cap Gemini's or's website for the training schedule. And please consider the following to be me own interpretation (right or wrong) of the course's material and the many lively debates that followed.

Scrum or don't Scrum at all

Some call them 'extremists', but many Scrum Masters claim that the only way to implement Scrum succesfully is to implement Scrum completely. I mostly agree with this (strong) statement. Scrum makes a number of important assumptions about how people work, how teams work, how businesses work and what problems occur during traditional approaches. Scrum has formulated a powerful answer to make Development Teams more capable of delivering business value with product owners in an iterative approach. Just implementing some parts of Scrum is bound to cause implementation issues as this undermines Scrum's delicate balance between business value, flexibility and stability. Scrum tries to achieve flexibility by allowing the Product Owner to prioritze and populate the Product Backlog as he/she sees fit. But it also tries to achieve stability by allowing the Development Team to work on a Sprint Backlog in isolation and provide structure by it's Sprint pattern. It empowers all parties involved by capitalizing on their goals and motivations. Implementing Scrum partially will not work:

  • Doing only Daily Scrums: Although this might be used to facilitate intra-team communication, its use will be limited without a Scrum Board, a Burndown Chart and team members that can determine their own planning for the day;
  • Doing only Sprint Retrospective: Although learning might be facilitated, teams must feel empowered to make the changes they see fit and allow self-organization. Otherwise, Sprint Reviews can be very demotivating;
  • Doing sprints without 'shippable' results: If sprints are executed without requiring 'potentially shippable' results, there is little pressure and little focus on Business Value. It might lead to a large backlog of 'Un-done' work, which might bite the team later;
  • No real product owner: Working with substitute Product Owners (such as an analist) might work, but working with the actual (real) Product Owner will avoid conflicts and will improve involvement by the customer and a deeper understanding of the complexities of software development. An actual Product Owner can also learn a team a lot about what Business Value actually means in the customer's context;
  • Estimating in hours instead of points: Estimating in hours does not allow the calculation of velocity, which is central to Scrum's empirical approach. See this post for more information;
  • Micro-managing: If a Scrum Master feels the need to micro-manage teams, this will defeat all self-organization and all advantages it brings to efficiency, effectivity and motivation. Members will prefer to be told what to do, rather than taking responsibility. In the end, the latter is always more motivating;

There are many more examples, but the point is that the basic rules of Scrum should be taken as-is. There is no compromise. Thankfully, Scrum is only explicit about a few ground rules. The rest is up to the Development Team, the Scrum Master and the Product Owner. A good rule of thumb is take the basic rules as-is and make all the other things discussion topics within the Development Team. E.g:. The team does not have to do the Daily Scrum at the time designated by the Scrum Master; they can decide by themselves what the best time is for them, as long as they do it.

The Product Owner is one person

Don't allow sprints with multiple Product Owners. It is very important that a Development Team can work with one skilled Product Owner. This is important because it creates stability and clarity for all involved. There is only one person who determines what goes in the Product Backlog and how it is prioritized. This avoids frustrating scenarios where a team gets told A by one product owner, but B by another. Teams should be able to rely on a single person to decide for them what they should work on. The organization and prioritization of a Product Backlog is of course a joint effort between stakeholders, CEOs and key users. But the Product Owner should be given a full mandate to make decisions on behalf of all the stakeholders. The Product Owner is also the only person who decides which parties to invite to the Sprint Planning and Sprint Review meetings. Additional stakeholders can (and probably should) be invited to a Sprint Review meeting to evaluate the result, but this is not required.

Power to the team

Scrum empowers the team to become self-organizing, like the socio-technical approach it is partially based on. Although this sounds straightforward, I feel that this is where the biggest paradigm shift is required of practicioners. Managers are used to thinking of people and teams in terms of 'cogwheels' that perform role X or Y and that they should be told in detail what to do. In Scrum, these concepts are removed. Instead, people are considered as intelligent, professional, driven and mature beings. Rather than telling them what to do in detail, they are given freedom to take control over how to perform their work. This will greatly improve motivation, involvement and team identity. All of Scrum's rules should be understood from this perspective. As an organizational psychologist I can really enjoy learning how cleverly Scrum incorporates many, many of the insights that modern organizational psychology has given into what motivates people, what creates and reduces stress and what facilitates the formation of high performance teams. 

The Scrum Master uses Servant Leadership

Scrum Masters do not micro-manage. They don't tell teams what to do when it comes to transforming the Product Backlog into realized functionality. Instead, the Scrum Masters focusses solely on making sure that all the parties 'play by the Scrum rules'. The Scrum Master is also responsible for teaching Scrum to the Development Team and the Product Owner. Preferably, suggestions for change should come from within the team and be supported democractically by all. But the Scrum Master can take a more authoritarian approach when it comes to the basic rules ('Yes, you will do a Daily Scrum' and 'Yes, the Sprint Retrospective is performed and will take one hour'). The Scrum Master should also be perceptive to conflicts within teams, but should not feel the responsibility to resolve them him/herself. This is up to the team, but supported by the Scrum Master. For a Scrum Master it is useful to learn a more Socratic approach to management. Rather than stating how things should be done, a Scrum Master should ask if the team has done the best it can, how it can improve, if it sees grounds to change procedures, etc. When a Scrum Master feels that a team is missing opportunities to grow, this should not be forced upon the team but stimulated with questions ('Do you think there are other ways you could have done this?').

When a sprint's functionality is 'Done'

A good 'definition of done' is very important to the success of a sprint. This definition needs to be created and shared by the product owner and the development team. It describes the rules that determine if a Product Backlog item can be considered as 'Done'. This definition is important because Scrum focusses on delivering a 'potentially shippable' product at the end of every Sprint. Whether or not to actually release the sprint result is a decision that only the Product Owner should take. This means that the team should always work from the assumption that the Product Owner will release the Sprint Result shortly after the Sprint Review meeting. A good rule of thumb that is that this means (so to speak) that actually releasing the Sprint result is a matter of hitting a button and should not consume valuable time from the current sprint. Migration scripts, support manuals, release procedures and publish scripts should all be in place.

The rules that make up the definition of done should be specific and (whenever possible) SMART, like:

  • The item is done when relevant test cases for business rules have been written and tested;
  • The item is done when it has passed Acceptance Tests defined by the Product Owner;
  • The item is done when unit tests have been written and passed;
  • The item is done when the code has been reviewed by at least one peer;
  • The item is done when any changes that have been made are documented in a (short) changelog for the Sprint;
  • The item is done when the HTML is '(X)HTML valid' as determined by the W3C validator;
  • The item is done when the code has been checked into a version control system;
  • The item is done when UI parts pass the Web Accessibility Initiative (WAI) of the W3C;
  • The item is done when potential security holes (XSS, SQL injection) have been checked and closed;
  • The item is done when it has been documented for end users;

These are just some examples. It is important that the definition is evaluated and agreed upon by the Product Owner and the Development Team during every Sprint Planning meeting and updated during the Sprint Review meeting whenever the team feels that this is necessary. The definition of done applies to all items in the Product Backlog (although some rules might be relevant in every case). Specific criteria should be addressed per item in the Product Backlog as 'Acceptance Criteria' for that item. For example, if the team has to build a poll functionality (one item) that should be capable of dealing with 10.000 concurrent voters, define this as an acceptance criteria. Acceptance Criteria should also be as specific as possible and describe which 'rules' the Product Owner will follow when evaluating if the item has been completed.

In some cases, acceptance criteria might be open to prioritization. For example, a Product Owner may desire to deliver a system that can support a million simultaneous users. Because the system under development might not have to deal with this for a while, the Product Owner can add this criterium as an item to the Product Backlog instead. It can now be estimated and prioritized as any other Product Backlog item. This might also apply to making an application accessible for color-blind users. Of course, the Development Team is free to suggest additional items to the Product Owner if they feel these are important to generating Business Value (directly or indirectly). The final decision, however, is up to the Product Owner.

The Product Backlog should contain all the work a Development team performs

A lot of blogs I've read argue that the Product Backlog should contain only items that are functional to End Users and generate Business Value. This restricts using the Product Backlog for non-functional items, such as infrastructural concerns (hosting, setting up staging environments, architecture). In these cases, Product Backlogs are usually exclusively formulated in terms of User Stories. This makes it very hard to address non-functional concerns like those mentioned above and has led some to write create User Stories such as 'As the Team, I want to address concern X'. This feels quite forced. Thankfully, Scrum does not require the Product Backlog to exclusively contain functional items. It does focus on generating business value. But sometimes, business value can also be generated indirectly (or made possible) by important non-functional items. Most web application projects will also require some sort of hosting environment to be set up, or a migration script to be written to migrate existing data. Although this could be added to a definition of done or as an acceptance criterium for a specific user story, the items can also be added to the Product Backlog. This allows them to be estimated by the team and prioritized for the Product Owner. If the Development Team would like to write technical documentation and can argue why this generates Business Value ('we will need less time to solve problems' or 'a support team can more quickly diagnose and resolve issues'), the Product Owner can decide to make this a priority instead of some functional item. The key is to let the Development Team explain what they need, but give the Product Owner the final decision.

The importance of Backlog preparation

Backlog preparation is the process of preparing the Product Backlog for a Sprint Planning meeting. It is pretty much an ongoing process during a sprint and addresses several questions:

  • Are there enough items in the Product Backlog that are specified at a sufficient level of detail to populate 1 or 2 upcoming sprints with at least 4/5 items per Sprint?;
  • Are the Acceptance Criteria for upcoming items clearly specified?;
  • Are items estimated and are the estimates still acceptable?;
  • Are there any items that are too large and should be decomposed?;

It may be a good idea to schedule preparation meetings to address new functionality, decompose large upcoming items into smallers and re-estimate items. But preperation can also be done as part of the work, without special meetings. As a rule of thumb, a Development Team should reserver 5% to 10% of their time for sprint preparation. For me, an important focus of preparation is to make sure to have at least 5+ items on the upcoming sprint. Otherwise, situations may arise in which a team is working on one large item during a sprint rather than a lot of smaller ones. This makes it difficult to track progress.

The importance of 'soft' skills

Although not specifically addressed in the course itself, Scrum puts a heavy emphasis on the team's 'soft' skills. In contract to technical skills, such as C# coding, writing unit tests, setting up databases and writing queries, Scrum requires a lot in terms of communicaton skills, conflict negotiation, giving and receiving feedback, asking the right questions and dealing with team dynamics. Sadly, these skills are not usually addressed as part of Scrum, but they are vital to it's success. When you want to implement Scrum, make sure to spend time on these skills and train your team. See my post about communication skills for some simple pointers.

But, in the real world .. (conclusion)

Most questions in Scrum courses start with 'Ok, but in the real world....'. This is usually followed by an implicit observation that Scrum sounds really good on paper, but that it will not work in the real world. Thankfully, more and more companies are effectively using Scrum. Of course, implementing Scrum will often be very hard. Not because it is utopistic, but because our organizations and cultures are ingrained with values that run counter to what Scrum tries to achieve. In most companies, individuals are often (explicitly or implicitly) assumed to be incapable of making informed decisions and are mistrusted when it comes to taking responsibility. There is a certain cynicism that has crept into how we evaluate employees and teams ('if you are not at work at 9:00 AM you are not working hard enough' or 'If you deliver X lines of code (no matter the quality or the value it generates) you are doing your job'). Breaking through this cynicism is an important first step when implementing Scrum. The many organizations (like our own) that are either effectively using Scrum or are working hard to implement it, can tell you how well it works. As long as you play by the rules. Power to the Team!, I say!

Christiaan Verwijs
Christiaan Verwijs

Scrum Master, Trainer, Developer & founder of Agilistic