Chris Belknap

Many Scrum Masters fall into the trap of quoting the Scrum Guide verbatim, mistaking recitation for servant leadership. Quoting the rules isn't the same as understanding them. This post explores why simply reading from the Guide can frustrate teammates and stakeholders, lack context, and hinder team growth. Here's what you can do instead. Try taking on a coaching stance to foster understanding through relevance, reflection, and powerful questions. To help teams truly embrace Scrum, the focus must shift from quoting the rules of the game to connecting with the “why.”

The Mid Sprint Check-in, Demo, or Review: these meetings make Scrum much less effective while giving the illusion of control and predictability and may be masking other problems. Does your Scrum Team need another meeting?

The Scrum Team consists of three accountabilities: Developers, Product Owner, and Scrum Master. Yet Scrum Team accountabilities and responsibilities can be confusing, misunderstood, and lack shared understanding between its members and the organization. This exercise makes transparent the accountabilities of each team member by driving conversations about what team members agree on and where there are gaps. Use this exercise when new teams are formed, or when you see misunderstandings and knowledge gaps around Scrum Team accountabilities and expectations.

Great facilitation makes it easier for everyone to participate, collaborate, and find shared understanding to reach the desired objective. Facilitate effective Scrum events and other meetings by starting with a well-thought-out facilitator guide.

The Scrum Guide provides no reference or guidance on how to get started with Scrum. That's because Scrum is a lightweight, minimal framework to encourage self-organization. I have heard it stated that Scrum is intentionally incomplete. There are no special Sprints in Scrum, such as Sprint Zeros, either, which leaves many new to Scrum wondering how to get started. Since I've gone through this myself and have helped a lot of new Scrum Teams get started over the past decade, I decided to share what I do and write down the recommended steps I typically take with a new Scrum Team to get started. This is part one of a two part series. If you only had one day to get started... Let's say that you've joined a new Scrum Team as the Scrum Master for an important new flagship product, and the stakeholders are eager to see the team get started and make progress. They've heard about Scrum and want to know how long it will take before the first Sprint starts. Leadership will support you with whatever the team needs to be successful. So, how long will it take to start Sprinting? And, what needs to be in place before the first Sprint? What would be your answer? One day? One week? One month? My answer would be "we can start Sprinting in one business day or less!". The only caveat is that we need a Product Owner and Development Team to join me, the Scrum Master. You won't be successful with Scrum without the roles filed. But just one day you ask? Yes, one day, this isn't waterfall where we need to plan everything up front. I have spoken with Product Owners and teams who have spent weeks, sometimes over a month, trying to capture everything in the "perfect" Product Backlog, only to find out that they didn't know everything up front. And worse, some of the Product Backlog was never implemented. Don't get stuck in the old, traditional waterfall way of working! I have worked with teams who create enough Product Backlog items to get started in less than a day, and they were still successful while minimizing waste. Remember, you don't need to know "how" the Product Backlog items will be built, that will be determined in Sprint Planning and throughout the Sprint by the Development Team. And you don't need an exhaustive list of Product Backlog items either, you will discover new items as you get feedback from stakeholders, and even better, customers and end users of your new Product. That's the beauty of empiricism, we'll make decisions based on what is known. You don't need an exhaustive list of Product Backlog items, you will discover new items as you get feedback. Scrum only requires these pieces be in place before the first Sprint starts: A Scrum Team consisting of a people fulfilling the roles of Product Owner, Scrum Master and Development Team (optimal size would be 3-9). Enough "Ready" Product Backlog to fill a Sprint (Sprints are limited to one calendar month). A definition of "Done". The Product Vision I add in one more task to get started, which is not required by Scrum: the Product Vision. I recommend this be the first acton you take above all else. Consider the Product Vision a complimentary practice that you will use to kickstart your initial Product Backlog conversation, and inspire your team in upcoming Sprints. I like to include everyone when coming up with the vision, not just the Product Owner, including the Development Team. There are many ways to facilitate a Product Vision that have been documented elsewhere, so I won't repeat those. Here are two of several ways you can explore to create the Product vision. Again, this isn't required in Scrum but will make a big difference now and in the longer term, so spend some time doing this. Product Box, from Innovation Games The Elevator Pitch Template, from ProdPad The Product Backlog As I mentioned above, you don't need an exhaustive list of Product Backlog items to get started, because the Product Backlog will emerge over time as more is learned. But you'll need a few Product Backlog items to fill the upcoming Sprint. Another important tip is that you don't need to know how Product Backlog items will be implemented at this point, as that will be figured out during Sprint Planning and the Sprint. Stick to the "what", not the "how". In part two of these series I am going to talk about using Story Mapping to determine a Minimal Viable Product (MVP), Roadmap and release candidates. But for now the best advice can give is to come up with some Product Backlog items that are needed to get started. Some of these items may even be technical in nature, such as architecture or tools (e.g. The need to set up CI/CD and automation), and that's fine. But remember to deliver some functionality to keep your business stakeholders interested and to validate those technical items. The Definition of Done Now let's discuss the definition of "Done". In Scrum a "done" product Increment is required every Sprint, and that's important. It doesn't mean that you have to release the Increment, but it has to be in a 'potentially shapable' state. So as a Scrum Master you'll have to figure out a way to facilitate a definition of "Done" for your Development Team. A good first place to look is to see if your development organization already has some standards in place. From the Scrum Guide: If "Done" for an increment is not a convention of the development organization, the Development Team of the Scrum Team must define a definition of "Done" appropriate for the product. If there isn't one at the organizational level, your Development Team needs one! If you've not taken a Professional Scrum Master course, I highly recommend one as we discuss this topic in depth. But if you need to get started right away, here are some articles which should help you: Improving Your Definition of Done, by Simon Reindl Why Scrum Requires Completely "Done" Software Every Sprint, by Christiaan Verwijs Walking Through a Definition of Done, by Ian Mitchell Conclusion That's it, the Product Vision and three items required by Scrum are all that is needed before you start your first Sprint. Is that perfect? Nope, it isn't by any means, however in my experience it is best to dive right in, and make transparent what else will be needed in the future. I suspect my list may be different than yours, and that's okay. There is no perfect way to get started or set of best practices when it comes to building complex products. I encourage you to experiment to see what works for your teams. In part two of this series I will discuss what else I do to continue the momentum, and share more details on things like team building, story maps, roadmaps, lean canvas, metrics and more. Scrum on!

In my role as an Agile coach and Scrum trainer, I get the chance to talk to a lot of Scrum Masters and teams.

When working with teams new to Scrum, one of the questions I usually ask is, "What are your plans to describe non functional requirements (NFRs)?". Typically the Product Owner already has a good handle on functional requirements (i.e. new product features), yet what about the product's performance, security, system availability, and usability? How should those types of items be described? Should NFRs be added to the Product Backlog? What if the NFR applies to most of the Product Backlog items, we'd be repeating ourselves. Scrum does not prescribe solutions, and what works for one team may not work for another. There could be several valid ways a Scrum Team chooses to handle NFRs. In this article I discuss what an NFR is, share a few examples of NFRs, and provide you with some ways for your Scrum Team to handle them. What is a Non Functional Requirement (NFR)? Let’s start by revisiting for a moment what the Scrum Guide states about requirements in general: [The Product Backlog] is the single source of requirements for any change to be made to the product. The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. The Product Backlog is an ordered list of everything that is known to be needed in the product. Whereas functional requirements convey what features the Product Owner would like built, non functional requirements (NFRs) describe system behaviors, attributes and constraints, and they can fall under multiple categories. System performance, security, failover, capacity, scalability, usability, and reliability are just a few categories. There are hundreds of examples. I once worked on a web product at a large financial firm, which managed over 5 trillion dollars of investor’s assets. The last thing anyone at the company wanted was to end up on the front page of the Wall Street Journal for a security vulnerability! This firm also had multiple products, built in silos over the years by different development teams, and needed a way to keep its company branding (color, fonts, images, etc.) consistent, since customers navigated from one financial product to another (e.g from their IRA account to online banking). In other words, even though the firm sold many products, they needed a seamless experience for their customers. Let’s look at a few specific examples: All source code must be run through a static security testing tool to be analyzed for security flaws, with all issues remediated (security). Every web and mobile web pages related to brokerage trading transactions (stocks, bonds, mutual funds) must load in under 2 seconds (performance). If a customer has logged into our site and the session is idle for more than 10 minutes, automatically terminate the users session and log them off the system (security). All customer facing web pages will use the corporate style guide colors, fonts and corporate approved logos (branding). All web pages must support our visually impaired customers through our department Accessibility guidelines and best practices (UX Accessibility). What Are My Options For Describing NFRs? Now that you know what an NFR is, there are at least three ways to explain how to handle the NFRs in Scrum. This is where experience and experimentation comes in to play. You won’t find the term non functional requirement, or NFR, in the Scrum Guide, because it is up to the Scrum Team to figure out the best way of describing them. In the Definition of “Done” For NFRs that apply to the entire product Increment and across all Product Backlog items, the most common solution is to describe the NFR in the Definition of “Done”. From the Scrum Guide: If the Definition of “Done” for an Increment is part of the conventions, standards or guidelines of the development organization, all Scrum Teams must follow it as a minimum. If “Done” for an Increment is not a convention of the development organization, the Development Team of the Scrum Team must define a Definition of “Done” appropriate for the product. As an example, I was working for an insurance company who provided auto insurance quotes for mobile web users. Our Product Owner, who was deep into analytics, discovered that mobile web users abandoned the site at a high rate if a page did not load in two seconds or less. Therefore after several Sprints, this is what we added to our Definition of “Done”: For customers using iOS and Android on a 4G network, all mobile web pages must load in under 2 seconds. This requirement made sense to be placed in the Definition of "Done" because it applied broadly. In fact we had multiple Scrum Teams working on this product, and they shared one common Definition of "Done". All the Scrum Teams had to be "singing from the same songbook". In the Product Backlog Sometimes an NFR won’t apply at the macro level for every Product Backlog item (PBI) or at the product Increment level, therefore it isn’t a good fit for the definition of “Done”. It is then perfectly acceptable to describe it in in the form of its own Product Backlog item (PBI), making the work visible in your Product Backlog. Let’s go back to the auto insurance quote example. Once Sprint the Scrum Team built a report for Sales reps to make follow up calls to customers who did not make an online purchase. It was fairly common for customers to drop out of the sales funnel for various reasons. During the Sprint Review, feedback was given that the report was displaying NPPI data, which was a huge security issue. In the web site's interview forms, Non-Public Personal Information (NPPI) was asked for to provide an accurate auto insurance quote, such as social security number, date of birth, and drivers license number. To remedy the situation, a Product Backlog item (PBI) was added by the Product Owner to mask the fields on the report, and the team fixed the issue in the next Sprint. In the Product Backlog Item’s Acceptance Criteria Adding Acceptance Criteria to a Product Backlog item is a third complimentary way to describe your NFR. The Scrum Guide does not mention Acceptance Criteria, but it is a great practice to answer the question "I know that this feature is complete when...". By the way the Scrum Guide does call out something similar, using the term test descriptions. Product Backlog items often include test descriptions that will prove its completion when “Done.” I was once working with a Scrum Team who was building a feature to handle online credit card payments, and one feature they were implementing was to send an email confirmation once a customer’s credit card was authorized and payment was made. The email server software the team was interfacing with was built to send batches of emails every 10 minutes. The NFR was that the email had to be triggered and sent from the email server within 30 seconds of a processed payment, and it was expressed using Acceptance Criteria. Otherwise worried customers would call the Help desk, thinking that their purchase did not complete. Closing In summary you now know what a non functional requirement (NFR) is, and how to handle these types of system requirements. I've offered three common ways to describe non functional requirements (NFRs), and I am sure there are more. The Scrum Guide is not a 'how to' guide with prescribed answers, and there are usually multiple ways to solve problems when dealing with complexity. I would encourage teams to experiment to determine what works best for them. I also like to use this for an interview question to get a sense for a candidate's experience and depth, so feel free to try out this question in your next interview. What alternatives do you use to describe your NFRs? Scrum on!