Daria Bagina

In my latest video, I’m sharing a useful model that can help you better serve your Scrum Team and set them up for success.

In this blog post, PST Daria Bagina discusses the value of creating a Community of Practice for Scrum Masters.

Every Scrum Team is different. Even when two teams seem to have similar challenges, similar products, and similar environment, they would not be actually the same. So your approach will change depending on the situation. This blog post gives suggestions on how to assess your teams.

Velocity has become a word specifically associated with measuring how well a Scrum Team is doing. This metric is often associated with negative feeling new Scrum Teams are feeling towards Agile in general. However, the issue with velocity is not the metric itself, but rather how we use it. In this video, I will be sharing how to use and how NOT to use velocity with a few examples and metaphors. Velocity and performance I often encounter Scrum Teams that have a very adverse reaction to velocity and don’t want to even track in. Teams (and Scrum Masters alike) are worried about the points on stories that they couldn’t finish. How do you split unfinished user stories so that the team doesn’t lose points in the Sprint? They did the work ofter all. And here is where we see the biggest problem, because velocity is used as a performance metric. The team knows that stakeholders will be judging them based on that number. Is it consistent? Is in increasing? It has to increase, right? Wrong! Velocity does not represent performance of the team, nor does it represent the value delivered. It just represents an average amount of work a Scrum Team usually completes within a Sprint. It’s important to note the two words in this last phrase: “average” and “usually”. What they represent is uncertainty. Remember that velocity is based on the estimated effort and complexity of work before that work actually started. And since product development lies in a complex domain, this estimate is by default most likely is incorrect. What does it all mean? We need to go back to why Agile even came around and what relative estimation really is. Unfortunately, this blog post is not about agility in general. If you want to learn more about the topic and truly understand Agile, I recommend checking out my online course “Success with Agile and Scrum”. It’s a perfect place to learn key aspects of agility and actually implement them in your real work. Velocity in planning Ok, I clearly stated that velocity is not good for measuring performance or value. “Then it must be just a useless metric created to pressure the teams to deliver faster?” Actually, velocity is a very useful and practical metric that can bring a lot of value to Scrum teams when used correctly. It can help teams identify areas of improvement and become more successful with Agile. The correct use of velocity is “for the team by the team”. It’s an internal metric that a Scrum team can use to plan their Sprints and their Product Backlog. Since it’s an average of how much work a team usually completes within a Sprint, then it can help how much work to take into the next Sprint (approximately). It’s a great way to plan based on data you have collected in the past Sprints. It removes the guesswork from Sprint Planning and allows the team to focus on the WHAT rather than HOW MUCH. And when I say “internal metric” it means that it is used by the team only. It’s not something that needs to be presented externally as for anyone outside of the team this number won’t mean anything. A good way to use this externally, is when you plan for specific scope or for a specific deadline. This is where the Product Owner would be able to look at the Product Backlog and based on average velocity forecast how much scope might be completed by a certain date or how much time a team might need to deliver a certain amount of scope. There are many important metrics that can help you measure the success of Scrum and help your team find opportunities for improvement. Head over to the Agile Metrics section in my blog to learn more about it. As always, a question to you for some self-reflection: How do YOU use velocity? Does it bring the value it should? And if not, what should you change in collecting or tracking velocity to use it properly?

One of the things you do as a Scrum Master is help your Product Owner in different aspects of their role. It doesn’t mean that you need to know how to do their job yourself, but you should be able to bring valuable practices and techniques to their attention.

In this video, I'm talking about what to look out for when talking about customer needs and how to help your team truly understand their customers.

The key point of Scrum (and Agile for that matter) is getting something valuable into the hands of our customers more frequently. However, this concept, closely linked to the Definition of Done, is often misunderstood and misinterpreted. With the release of the new Scrum Guide back in November 2020, many people were taken aback by some of the precisions made in the text. While the guide itself became less wordy, it added some clarifications – now you can’t just skip those rules. Unfortunately, it raised some additional questions from the community about the aspect of Done. In this video, I’m talking about what 'Done' really means and why this is the key thing you should be focusing on achieving. I also give some tips for Scrum Masters to help figure out what is wrong if the team is not getting to Done. Long video ahead - buckle up! {"preview_thumbnail":"/s3/files/styles/video_embed_wysiwyg_preview/public/video_thumbnails/4jQBX9Ep4zw.jpg?itok=oOrNTpAz","video_url":"https://youtu.be/4jQBX9Ep4zw","settings":{"responsive":1,"width":"854","height":"480","autoplay":0},"settings_summary":["Embedded Video (Responsive)."]} Now it's time for reflection. Share in the comments 👇: is your team delivering Done? And if not, where does the link break: Done, transparency, trust or courage?

This is the third and last video on agile metrics for Scrum Masters. In my previous blog post, I talked about measuring the quality of Scrum implementation on your team and organization.

This is the second installment on agile metrics for Scrum Masters. In my previous article, I talked about delivering Done increment every sprint. In this part two, we’ll talk about establishing Scrum as defined in the Scrum Guide. As we discussed, this is one of the accountabilities of a Scrum Master. So how can we evaluate how well a Scrum Master is doing in regards to this? Scrum is being followed with all elements, rules, values and principles You represent Scrum in your team and organization. It does not mean that you are a Scrum Police forcing everyone to follow rules without understanding why. As a Scrum Master you are there to help everyone understand and accept the framework, and follow it mindfully. There are some metrics that can help you measure success in this area. They are mostly qualitative, but can be turned into quantitative metrics with some creativity: Are all events, commitments, roles, and artifacts followed by your team? Scrum has three roles, five events, three commitments and three artifacts. As the Scrum Guide says: “Each element of the framework serves a specific purpose that is essential to the overall value and results realized with Scrum. Changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum, covers up problems and limits the benefits of Scrum, potentially even rendering it useless.” If not all elements are present, you’ve got some work to do. What is the overall level of understanding of Scrum framework, empiricism, and agility? While your team might be following Scrum exactly as defined in the Scrum Guide, they might be just going through the motions. That is what we call ‘mechanical Scrum’ or ‘Zombie Scrum’. So quality of your Scrum also matters. We can define that quality by evaluating how well the team and the organization understand the foundational concepts and principles of agility and the Scrum framework. Here are some important points to evaluate: the level of understanding of complexity of product development practical application of agile values and principles the purpose of each Scrum element (such as events, roles, commitments, artifacts) empirical process control theory importance and connection between transparency, inspection and adaptation practical application of Scrum values in work of the team self-management and cross-functionality This will be up to you as a Scrum Master to define how to best evaluate the level of understanding of these concepts. Whether through a self-assessment, a quiz, or a discussion, you can find a way to turn this information into a metric to evaluate your success. Observe and evaluate the quality of the Scrum implementation in your team and your organization to help you measure success. Stay tuned for part 3 on agile metrics for Scrum Masters where we will talk about the effectiveness of a Scrum Team.

How can you evaluate your success as a Scrum Master using metrics?