As a Beginning Scrum Master- I don't just take notes...
Scrum, Daily Scrum, Refinement, Sprint Review, Sprint Retrospective, Sprint, Stand Up, Kanban, Lean, Black Belt..
The list goes on and on. When I started as a ScrumMaster it felt like my head was spinning between the technology terms like “on-prem”, Java and lambdas. Jumping from event management into the world of Scrum is an adventure that continues to teach me new words and ways of work. So let’s break down some of the things that can happen as a beginning ScrumMaster.
You get asked to take notes and set up meetings: This was my first encounter in the Scrum-world. I readily stepped up, excited to learn about making positive change and delighting the customers. Then I quickly become bored and wanted more voice in the conversations going on. Why was that? Just an incorrect role? Misalignment of responsibilities? Did I misunderstand the Certified ScrumMaster class I went to?
None of the above. As it turns out, a ScrumMaster is not supposed to take notes or set up meetings. Yes, they can help in that way, but so can anyone on the team. As a ScrumMaster, I’ve found that my actual responsibilities include watching and listening for that moment in conversations when things dive too deep, go off-topic or everyone seems to be losing interest. They also include asking the hard questions, like why are we doing this in the first place? What problem are we trying to solve?
In the Daily Scrum or Stand Up in particular, this involves asking questions like, “Are we going to complete the work we initially committed to? If no, why not? Should we really be bringing in different work? Does the Product Owner know that we won’t make our commitment? Why aren’t we swarming to get the work done together, as a team?”
Being a ScrumMaster doesn’t automatically make anyone an expert, specialist or even good at facilitation, strategy or communication. This looks different for each person and each company. However, becoming a ScrumMaster has allowed me to see why facilitation isn’t about taking notes and scheduling meetings. Or how strategy isn’t just high-level executive work, but something that teams need to use in every day development. It has also shown me that communication is so important when it comes to persuading a team to take a risk.
Have you ever thought about how one role can be armchair psychologist and courageous proponent of change at the same time? The Certified ScrumMaster class explains how our interactions directly impact the work being done for our organizations. It teaches us that first we need to trust ourselves, our teams and our organizations and the ScrumMaster is a key part of that.
If you are interested in learning more, click here to connect with our team or see the upcoming classes on the calendar.
Aren't Product Backlog Items just User Stories?
So just what is a product backlog item in the Scrum framework? One of the Scrum artifacts is the Product Backlog. A Product Backlog Item, or PBI, is similar to the intent of the user story. It was a place to note conversations that needed to be held with the Product Owner and anyone else necessary to flush out more information about the item. As conversations are held, results of those conversations can be added to the PBI in plain old words. No prescription necessary!
Are Product Backlog Items the problem?
“As a <>, I want < > So that < >. ”
In nearly every Certified ScrumMaster (CSM) class, we have face template-zombieitis. This is the condition caused by the User Story template. User Stories are not required in Scrum nor are they one of the Scrum artifacts. One only has to read the official Scrum Guide to validate this: https://www.scrumguides.org/
To be fair, User Stories were never meant to cause the template zombie condition. Just like Product Backlog Items, they were intended to be placeholders for conversations that were needed, or could reflect details of conversations that were already held. Somewhere along the line people seemed to forget this and began just trying to make stuff up to satisfy every field in the template, skipping the most important part: the Conversation.
So just what is a product backlog item in the Scrum framework? One of the Scrum artifacts is the Product Backlog. A Product Backlog Item, or PBI, is similar to the intent of the user story. It was a place to note conversations that needed to be held with the Product Owner and anyone else necessary to flush out more information about the item. As conversations are held, results of those conversations can be added to the PBI in plain old words. No prescription necessary!
As noted in the Scrum Guide:
PBI’s can represent considerations, questions, features, functions, requirements, enhancements, or fixes that constitute the changes to be made to the product in future releases.
Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when "Done"
Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion
Higher ordered Product Backlog Items are usually clearer and more detailed than lower ordered ones.
Product Backlog items that can be "Done" by the Development Team within one Sprint are deemed "Ready" for selection in a Sprint Planning. Product Backlog items usually acquire this degree of transparency through Refinement activity lead by the Product Owner with contributions by the Development Team prior to Sprint Planning. If a PBI cannot get to Done in a Sprint it may be split into smaller items during Refinement.
If you're ready to learn more- checkout Christian's upcoming CSM class here.