Coaching Scrum·4 min read

You Suck and That Makes Me Sad — Ken Schwaber Quote

A real email exchange with a CSM training alumnus worried about sprint burn-downs — and why the answer starts with 'you are not alone.'

The old saying “You suck and that makes me sad” comes from Ken Schwaber — back when I took his original Certified Scrum Master certification over 18 years ago (I became a CSM in January of 2004). Time flies.

I have been a Certified Scrum Trainer^® (CST) with the Scrum Alliance since 2006. In that time, I’ve traveled the world coaching, mentoring, and training teams around Implementing Scrum in the real world.

As one of the benefits of taking a CSM Training with me, you get access to me on an ongoing basis. I had a recent email thread with an attendee from many years ago that I received permission to share with you.

One of the reasons I want to share this with you is to remind you that you are not alone in the way you sometimes may feel when Implementing Scrum with your team, organization, or enterprise.

The Email Thread

Hi [name redacted for privacy],

Yes, you are an awful Scrum Master.

LOL NO YOU ARE NOT!!!!

I hope you are doing well. “Officially,” there is not a requirement to track a burn down chart per the Scrum Guide. Here is the only place “burn downs” are mentioned, from The Sprint:

Various practices exist to forecast progress, like burn-downs, burn-ups, or cumulative flows. While proven useful, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision making.

OK, with that out of the way — I’ve put some comments inline from your email below, with links back to the definitions in the Scrum Guide, not to be in “teaching mode” but to model how to find some of the answers per the Scrum Guide.

The attendee wrote:

We use Azure DevOps Boards for our scrum — in a given sprint we could be doing research tasks, development tasks, infrastructure work, DBA work, testing tasks. What I’ve noticed is that it really only makes sense for me to count development tasks towards our final burn down. Is that crazy??

My reply: Each team does this differently. Does it “work” for your team (remember, there are no Scrum Police)? If things ARE working, don’t mess around with changing stuff. I get the feeling that by you asking this, you’re feeling it’s NOT working.

Development tasks are really the main tasks we estimate with regards to hours. Testing tasks get a straight 1 hour across the board, and so do dev review tasks.

Gulp. Getting a small bad gut feeling. Remember it’s not individuals on a team delivering, it’s the Scrum Team. Why is there a separation of “development” and “testing” — and what value does it have to track burn down at that level? When I see this, an anti-pattern I recognize is that testing people get stuck getting the blame for “not finishing” because all the tasks were waiting to be tested the night before the Sprint Review — and then the perceived solution is to “add more testing resources,” which only compounds the problem and piles on technical debt.

Other tasks like DBA work, infrastructure work, testing, rely on people from other teams. There are times when they cannot get to their tickets for one reason or another that I have no control over.

More eek. That’s another anti-pattern. You don’t have any control over them. One thing that will help ease that problem: during Product Backlog Refinement, get those people involved in the conversation to get stories “ready” for the upcoming Sprint(s). And during Sprint Planning, do NOT pull a story into a Sprint unless the outside person has committed to getting that work done. Amazing stuff happens when you do this.

If a testing or infrastructure ticket is not complete on the final day of the sprint, I either put it in the Backlog or move it to the next sprint and ensure hours are updated.

Recommendation: keep moving any “leftover” stories to the Product Backlog instead of sliding them to the next Sprint. Just moving it to the next Sprint usually builds more and more technical debt. Just because a tool lets you slide stories into the next Sprint doesn’t make it a good or even acceptable real-world solution.

Then I run my final burn down. Am I an awful Scrum Master? Haha. Wanted to get your thoughts and make sure I’m not cheating the system here.

You are not awful. Actually, you are doing an AWESOME job asking these questions. It might be a good idea to chat with the Scrum Team (including the Product Owner) in an upcoming Retrospective or even an informal lunch-and-learn. One final resource: read Ron Jeffries’s “Dark Scrum” — it’s a few years old, but it spells out a lot of what you may be seeing and gives recommendations for getting the team out of that tailspin.

Hope this has helped. Keep being awesome. You are not “cheating” a system — that’s on the organization to reward for some strange things (like “how accurate are your estimates”) instead of focusing on delivering real value to your end users.

Would love to chat about a possible consulting arrangement — I want to put that out there as an option, and as you can see, I am here to help even without something formal.

What Next?

Was this helpful? Does it sound similar to conversations you’ve had with your team (or inside your own head)?

Contact me (with feedback) or connect with me on LinkedIn to discuss this more together.