7 Steps to Reclaim Your Scrum Master Super Power

Over the years, we have trained, mentored and coached hundreds of Scrum Masters. As we reflect on our experience, one truth seems to stand out - many Scrum Masters we meet are driven by a purpose.

Being a Scrum Master is not just a job for them. It is a calling to help others. It is a calling to live by principles and values higher than the principle of survival. The Scrum Master is accountable for the Scrum Team's effectiveness and they are most fulfilled when they are truly honoring their calling.

Unfortunately, in some organizations that claim to adopt Scrum, a Scrum Master is not always fully respected and they are only responsible for scheduling meetings, typing up notes, and being a management enforcer to deliver on-time, on-budget and ever-increasing scope projects. Being trapped in such roles can really affect the morale of purpose-driven Scrum Masters and they are unable to really utilize their super power of supporting the Scrum Team. But what can Scrum Masters do to avoid this pattern? If you are interested in the answers to this question, please join us in this webinar.

In this webinar, Professional Scrum Trainers Nagesh Sharma and Ravi Verma will share seven concrete steps that purpose-driven Scrum Masters can take to avoid and escape this trap while reclaiming their professional scrum master superpower.

Speakers

NAGESH SHARMA

Nagesh is very passionate about causing change and improve business results. His mission resonates with Scrum.org's mission of helping people, teams, and organizations solve complex problems. He has been engaged with many Large Enterprise transformations to a Lean and Agile approach, organizational dynamics, and creating high-performing teams.

His Agile knowledge & experience, along with his coaching and training abilities, offers him the perspective needed to guide people, teams & organizations to harness Agile as a competitive advantage.

Nagesh is a certified Intelligent Leadership Master Executive Coach by John Mattone, ACE Certified Coach by David & David. Managemen t3.0 facilitator and collaboration superpowers facilitator. Nagesh is also licensed to use Everything DiSC, STPI 360, Agility Health, AlDente, and Leadership Agility360 assessments.

He is an active speaker at various international conferences like Scrum Day Europe, Scrum Deutschland, Scrum Day India, Agilitytoday, Scrum Master Podcast, and Regional Scrum Gathering. Nagesh loves building communities and has been a track curation for Scrum Master Summit 2021 and Lead Official Scrum.org community meet-up in India.

RAVI VERMA

Ravi is the founder and Org Whisperer at SmoothApps and a Scrum.org Professional Scrum Trainer. He recently co-founded his second startup - Al Dente, a platform that helps Agile Coach’s and organizations empirically manage and improve business outcomes in tandem with Agile delivery frameworks like Scrum.

Ravi has 20+ year of Software Delivery and Consulting Experience with including Agile Enablement for companies ranging from 10 people to 10,000 people. Ravi is the creator of the Sabotagile Manifesto and Sabotagile Principles , co-creator of Software Code of Ethics, Scrum Pulse Webinars & Scrum Tapas Videos and co-founder of the meetup group Agile DevOps DFW. He is a certified trainer for Sharon Bowman’s “Training From The Back of the Room” courses and integrates brain-friendly learning into his training. He is also a Certified ROI Professional from the ROI Institute and integrates ROI Based Learning techniques into his training, coaching and consulting. Ravi is a Co-Active Scrum Coach and has completed 104 hours of training and 25 intense weeks of certification from the Co-Active institute.

As a grateful immigrant to the USA, Ravi felt a strong urge to give back to the country that adopted him and co-founded a non-profit – Agile For Patriots to provide free Agile training, certification, experience, mentoring and coaching to US Military Veterans and Spouses. Since its founding, Agile For Patriots has helped 44 candidates graduate from the program through 7 cohorts and is now preparing for the launch of their 8th cohort scheduled for Q1 2022.

Resource: https://www.scrum.org/resources/7-steps-reclaim-your-scrum-master-super-power

Read More

What Happens To The UNDONE Work In A Sprint?

Even a well-set team with clear objectives may fail to finish each thing when the sprint ends.

When the sprint was planned, the team might have thought about successfully tackling 6 Product Backlog Items (PBIs). But in reality, they might only address 4 or 5 PBIs. The rest of the items remain undone.

How shall we address the issue of UNDONE items?

DEFINITION OF DONE

To discuss what should be done with UNDONE PBIs, let us focus on the Definition of Done, as stated by professional scrum master training.

The Definition of DONE expresses the situation when an ‘Increment’ matches the quality parameters of the product.

An ‘Increment’ comes into existence when a PBI matches with the Definition of Done.

The definition, in this case, creates transparency for the team. Each team member has a shared understanding of the completed work, a segment of the ‘Increment’.

When a PBI does not comply with the definition, it is a mistake to release it. It can’t be even presented during the Sprint Review. Instead, it is regarded as a future consideration. 

But the question remains – how to estimate the unfinished PBIs? Is it possible to re-estimate them, and is it valid? Shall the team calculate the velocity for the tasks they have already completed? Let us dig deeper, starting with the concept of Partial Credit.

A Team should calculate the velocity for the Partially DONE work – YES or NO?

It should be clear at the very beginning – there is practically nothing as partially done.

When a team completes a segment of a PBI, the members receive partial credit or points, accounting for the velocity.

For example, if the team finishes half of the five-point PBI, the count is approximately 3, accounting for their velocity.

As far as I see it, the idea is not good. The velocity should be calculated only in cases of completed PBIs, which comply with the Definition of Done. It fulfils two objectives:

The velocity for the team becomes more relevant (not just a cosmetic parameter).

There is no cutting of corners. The UNDONE work again enters the PBIs and is re-estimated.

A prevalent question from the Management that a team has to address is reporting on the percentage of work yet to be done.

It isn’t easy to calculate the exact percentage. But, in most cases, there is an overestimation.

It happens because teams generally have a wrong notion that they are ahead of schedule. As a result, they over-estimate while calculating the velocity. One reason is the false expectation from the Management. I addressed this myth Velocity is Productivity.

An inflated value of velocity is good only momentarily. It provides a false pride of achievement. But, it is not useful practically. It sends wrong signals about dealing with PBIs in the near future.

Re-Estimation of the Unfinished Work

When there exists an undone PBI after iteration, the standard query of the team is whether it is right to re-estimate it. It is independent of any objective to get partial points.

The team members usually reason that a part of the work has been completed, and it might impact the estimation of the work left to be done.

Keep in mind that the overall size of the PBIs might increase. So, the estimation of the items remaining to be completed could rise, obviously higher than the estimate at the initial stage.

Thus, my recommendation here is shifting of focus from “velocity-driven” to “value-driven” planning.

But again, shall a team consider re-estimation?

Should the UNDONE work be re-estimated?

There are distinctly three valid reasons  that support the re-estimation idea:

After the completion of the work, the team members can estimate better.

It is a priority to plan and design the next sprint.

Finally, it is important to know when the work will be completed or DONE.

It is difficult to argue with pointer one above. So, I will accept it. My main focus is on the remaining two pointers.

The second pointer is about the necessity to plan and execute the next sprint.

Team members will generally be confused about the amount of work they should bring into a planned sprint when the PBIs have outdated estimation parameters due to incompletion.

They could say they would need more work to complete due to the backlog. Also, they could sound that they would resume from the beginning, complying with the current sprint goal.

Now, let us revert to the original query – should it be re-estimated?

My short answer is – YES. There are two reasons I want to put forward.

There might be a change in the complexity of the Product Backlog Item (PBI).

We generally don’t know whether the same team member will work on the Product Backlog Item.

Conclusive thoughts

It is the responsibility of every SCRUM Master to focus on helping a team define their definition of DONE, especially in cases when the team has not defined it.

The Definition of DONE undoubtedly creates more transparency. In addition, it provides shared understanding to each team member regarding the work segment completed as a component of Increment.

When a PBI doesn’t comply with the Definition of Done, the team should not release it or present it at the Sprint Review. Instead, the PBI returns to the set of backlogs to be considered in the near future.

Resource: https://www.tryscrum.com/blogs/what-happens-to-the-undone-work-in-a-sprint/

Read More