This is a bit of an aside, but I have a question that I'd like to ask the wider community here. How can you do a proper bug-bash when also dealing with Scrum metrics that result in a race for new features without any regard for quality? I've tried to do this with my teams several times, but ultimately we're always coming down to the end of the sprint with too much to do to implement features, and so anybody that "takes time off" to do bug bashing looks bad because ultimately they complete fewer story points than others that don't do it?

Is the secret that it only works if the entire company does it, like you suggest?

And yes, I completely realize that Scrum is terrible. I'm just trying to work within a system.

That's not a problem with Scrum, it's a problem with your team. If you're doing a bug bash every sprint, then your velocity is already including the time spent on bug bashes. If it's not in every sprint, you can reduce the forecast for sprints where you do them to account for it (similar to what you do when someone is off etc).

If you're competing within the team to complete as many story points as possible that's pretty weird. Is someone using story points as a metric of anything other than forecasting?

> Is someone using story points as a metric of anything other than forecasting?

Very nearly every company I've worked at that uses Scrum uses story points, velocity, etc., as a means of measuring how good you or your team are. Forecasting is a secondary purpose.

Don't teams assign points to their own tickets? So how could one compare the points between teams?

Yes. But many Sr. Leaders just see a number so it must also be a metric you can use for measurement. They do not understand it’s real use.

I picture a construction company counting the total inches / centimeters each employee measured every day. Then at the end of the year firing the bottom 20% of employees measured in total units measured in the last 12 months.

Sounds easy to game. Click a button to foo the bar is <pinky> one million points

Ahh the good old "Waterfall Scrum"

> That's not a problem with Scrum, it's a problem with your team.

I've seen that justification time and again, and it feels disingenuous every time it's said. (Feels like a corrolary to No True Scotsman.)

I've also seen scrum used regularly, and everywhere I've seen it has been broken in some fashion. Enough anecdata tells me that indeed Scrum, as stated, is inherently broken.

Ah the classic: How do I improve quality in an org 'without any regard for quality'? :)

But assuming that everyone cares about quality (I know, a big leap), what has worked for me is: tagging stories as bugs/regressions/customer-found-this and reporting on time spent. If you're spending too much time fixing bugs, then you need to do something about it. New bugs in newly written code are faster to fix, so you should be able to show that bug bashes make that number going down quarter over quarter which contributes to velocity going up.

Alternately (and not scrum specific) I've had success connecting a CSM/support liaison to every team. Doesn't give you a full bug bash, but even one outside person click testing for 20m here and there gets you much of the benefit (and their incentives align more closely with QA).

The team with the lowest bug bash participation this week is the victim err host of next week's bug bash.

Seems like another data point stating sprints don't make sense in real world projects ?

I'm kind of in the same boat re story points and Scrum metrics, but sometimes we can get management buy-in to create a ticket to do this sort of thing, if it's seen as high value for the business.

> because ultimately they complete fewer story points than others that don't do it?

Solution: don't measure story points

Only assign points based on a (n-1)-day sprint instead of a n-day one.

Why are you putting the blame on scrum if you don't even implement it? I did scum in a previous company and it worked fine. Nobody looked at the story points except the devs during planning. We had a honest discussion with the product owner every time and did find the time to do tech debt.

It wasn't perfect, but it worked well.

Granted, it required a very specific management, devs with the right mindset and constraints on the kind of projects that could be done (anything customer facing with a tight deadline was off for instance. We used that for the internal infra). So I don't see how you would build a plane at Boing with scrum for instance. Or anything that require very tight coupling af many teams (or hardware).

But for us (60 devs in a company of 200), Saas, it worked great.

We do a similar thing but call it a bug hunt.

Not only do we uncover bugs, it’s a great way to get the whole company learning about the new things coming and for the product team to get unfiltered feed back.