typical sprint in a wrong Scrum

If This is Your Sprint, You’re Doing Scrum Wrong. Here’s How to Avoid the Burnout Chart

We’ve been practicing Scrum for how many years now? 

I’ve seen Scrum-like versions of it working perfectly and by-the-book versions of it failing. It’s a philosophy, even though we read the guide as a user manual. Today, I’m sharing with you a real-life Sprint saga we’ve all been through many times. If this resembles your typical Sprint, you’re doing Scrum wrong, and you’ll not benefit from any of its goodness. Learn what to fix first.

Is This Your Typical Sprint?

I’m working as a software tester in a relatively young company. We don’t claim we’re doing Scrum, but using some of the terms. We do Sprint Planning on Wednesday. Of course, we have a Sprint Review, the Daily Standup, and Backlog Refinement. After the Sprint Review, we have a Retrospective, and the Product Manager is constantly ordering the Epics and the User Stories by priorities. 

It seems we are doing Scrum for a naked eye after all, but let’s dig deeper.

The Sprint is three weeks. The prerequisite for a Sprint to start is a refined and ordered backlog. I’ve rarely seen that, but it happened once in our team as well. It was one Tech Debt Sprint, and the expected result was pretty straightforward. 

In reality, the Sprint starts because the date has come. We close the previous Sprint with a few tasks remaining in the backlog, so the team has enough stories until the Product owner has something new written for the current Sprint.

When the Burndown Chart Turns into a Burnout Chart

The Sprint Planning is pretty quick, and the burndown chart looks perfect during the first week. The team is relaxed and happy that, for once, they’ll manage to complete the Sprint Backlog, catch up on Tech Debt, and even clean a good portion of the Bug Backlog. That’s right – there is a separate Bug Backlog.

Luckily, the Product Owner manages to manufacture the stories for the highest priority customer on Tuesday evening the following week. We know there are some parts to clarify further (all of it), but we’ve promised the customer, and we have to add it into this Sprint by all means. The burndown chart now looks like an airplane taking off, and we immediately ditch the lower priority tasks from the previous Sprint, including our hopes for refactoring. It’s Thursday, the second week of the Sprint. 

On Friday, another team breaks the main branch. All automation tests fail. Everyone’s blocked. The burndown chart is now a flat line. 

We continue on Monday, new week – new hope. It’s okay, we will work a couple of hours longer, but not too many, we’ll manage it! Then Git is down on Tuesday, and the top engineer needs to take a day off on Wednesday for a family emergency. The burn charts are bloody red. We cancel the Sprint Review and the Sprint Retrospective. We might not want to admit it, but someone gets yelled at.

Everyone works day and night over the weekend. The Team Lead misses his mother’s birthday and gets into trouble with his wife, who had plans for the weekend but had to take care of the kids because he had to work. 

The Sprint is Over, Here Comes the New Sprint

It’s Monday, the first day of the next Sprint. The Product Owner has now come up with several more detailed stories, the testers have found a couple of dozens of bugs. We have to redesign and cut the scope to a fifth of the initial plan. The customer is informed and is not happy. The whole UX has been struck out. We have to postpone the plans for two other major features if we want to deliver anything at all.

What Went Wrong and How to Fix it?

While reading this, you have probably identified several potential root causes, or you’re so frustrated because it is what your Spring looks like indeed, that you’ve stopped reading. 

Bear with me, I’m giving you a set of measures to apply right away and step out of this vicious circle. 

If you’ve been reading about Scrum for years, over and over again, and practicing it with various teams in various domains, you have a chance to get fluent in it. What’s left for the rest of us, regular engineers in the team described above is to have the Courage to Focus on our Commitment with Respect to the Product goal and Openly defeat our right to Create Value and deliver an inspectable Increment according to our Definition of Done. And this is a good Scrum.

So let’s see what we can do.

The Immediate Remedies for a Broken Scrum

Don’t Let Any New Items in the Sprint Backlog After the Sprint Starts.

That’s what Scrum says, isn’t it? It’s obvious, of course, we wouldn’t. 

I know, but we all let this happen. There are tons of excuses – it’s the PM/PO, and we see they’re just a man in the middle, the customer is in a hurry, there’s a business conference next month, and they have to show the demo, etc. We can’t just say ‘No’. Yes, you can. Just say No! 

If you’re the Scrum Master, help the team raise their voice. 

If you’re the Product Owner, don’t abuse your team’s helpfulness. 

Gather all together and agree on internal team rules about urgent and unplanned work. 

  • What do you classify as urgent? 
  • What other work can get paused if a critical item comes up? 
  • Split your Sprint by type of work and allocate time for new features, fixing bugs unrelated to the new feature, tech debt, urgencies, marketing. If one kind of work prevails over another, it’s not dramatic, but keep track and make sure to catch up as soon as possible.

Keep Your Backlog Healthy

You don’t need 100 items in your backlog, nor do you need 10. I don’t know how many you need, it depends on your product. 

If you’re the Product Owner, forget about velocity. Focus on your Product Goal and break it down into meaningful user stories. 

Don’t rely on refinement meetings, don’t wait for the team to ask. Once you’ve identified the next top product priority for the company according to the business, product, or marketing strategy, get a tester and an engineer, sit together, and define that user story.   

The greatest mistake I’ve seen is a Product Backlog full of one-sentence user stories continuously reordered. For the record, there were 237 user stories and bugs in there. 

Few of the stories were refined, but none entered a Sprint Backlog with the highest priority. 

Clear your priorities and keep the next 12 features that you’re absolutely sure must be implemented within the next quarter. Delete everything else. 

If you’re an Engineer, keep an eye on the product backlog and what’s coming ahead. 

You need to care. If the Product Backlog looks messy, then your next Sprint will also be chaotic. You’ll constantly be switching context, and if you have planned a vacation, well, I hope you’ve got flexible tickets. 

Use any opportunity to share your concerns with your Team Lead, your Scrum Master, and your Product Owner. 

By the way, if you and your mates try to limit your Work in Progress, you’ll suddenly start feeling much more accomplished, and it will also cause a considerable improvement for the Product Backlog.

Trust Your Definition of Done

Definition of Done is the most powerful, effective, and efficient quality assurance mechanism ever. And I don’t mean checks like “are there unit tests”? Well, not only. You as a Scrum team are in power to define what you refer to as a potentially shippable product increment. You have the right to define your own criteria. You could further demand that all deliverables that enter your engineering process comply with the corresponding Definition of Done. 

Once you start working on a user story or a bug, you must see it through completion according to your Definition of Done. What is the actual level of completion – this is again up to you. You, the Developers and the Product Owner, and why not even the Stakeholder, who you’ll demonstrate the increment to at the Sprint Review, decide together. But once you have it written, never compromise it.

 If it’s too much overhead and not so much value, revise and adapt, but don’t give up on your Definition of Done because, in the fast-paced Sprints, we all work, they are our path to high-quality without exhaustive testing.

Don’t Fall Into the Trap of the Misunderstood Scrum.

You can be agile – effective, efficient, responding to change, collaborative, bringing value, smart, and continuously improving – without practicing Scrum. For example, you can even transform your daily standups into something more meaningful. And remove the Sprint Planning too. That will not harm your agility (on the contrary).

What you can’t afford is to hide huge organizational, managerial, competency, and planning problems under the Scrum carpet. So don’t do that. If you’re not ready for Scrum, get ready first, find someone who can help you for real, and don’t claim you’re following Scrum by the book because it’s worthless and will do more harm. 

If you need to put things in order, start with the most significant pains and heal them one by one. Observe, measure, analyze, make a new change if needed or keep the practice if it’s working for you.

Scrum might be the proper framework for you or not. What matters is being courageous to face your issues and start fixing them. 

If you wonder where to start, or you’re still wandering through the Scrum guide, book a call, and I’ll show you the way.