Scrum Teams Without Developers - Is It Worth Logging Bugs As Backlog Items?
Does it really make sense to manage bug reports as backlog items, on non-development teams?
I'm a QA Manager using SAFe. One of my ARTs consists of several non-development scrum teams. They own products but outsource all development work to vendors. However, some of the teams have sprint stories to test the product once they receive new versions from the vendor. But this is something like a re-test or sanity test b/c the vendor is responsible for the primary testing. Nevertheless, bugs are normally found, requiring the vendor to fix and send a patch. The scrum team is inclined to log bugs in a spreadsheet. At first, my anti-pattern alarm was going off. But after spending time wrapping my head around their context, I'm not sure.
On dev teams, it's intuitive to estimate work around bug fixes because the bug fixing and testing will be performed by the team. But if that work is not performed by the team, logging bug reports (e.g., as Jira issues) seems a little weird. Let's not do it merely b/c dev teams do it.
I would love to hear from people with similar experiences.
In the situation you describe, who is making any commitments and what are they? What are those people accountable for?
Whoever is doing the work to meet commitments they have made, ought to manage their own work.
It doesn't make sense for your team to use Scrum, let alone a Product Backlog or "stories", if you're trying to use Scrum to validate a release from a vendor.
A conversation with the vendor's Product Owner to discuss the best way to communicate bugs might be a good next step.
@Ian, good question. This team is accountable for getting software deployed to retail stores. Sprint Backlog has work for staging the software in labs, running functional and integration tests, working with the vendor on new features or bugs, writing technical documentation and training for the retail store associates and helping the stores with UAT, installation and training.
@Chris I don't see a problem using Scrum here. But I do think this nuanced question I raised is relevant. We Agilistas talk a good talk about applying Scrum to non-dev teams. But I'm guessing we often slip back into practices that only make sense when the product devs are embedded on team.
I'm a QA Manager using SAFe.
I want to point out that the version of Scrum that SAFe uses is not the same version of Scrum that is described in the Scrum Guide. In their documentation they call it SAFe Scrum. I am not sure of all the differences it has from the Scrum described in the Scrum Guide but I know there are a few.
My first inclination is to do nothing. You do not mention that there is a problem that is impacting the ability to deliver. It appears that you are looking for us to provide you a reason to make a change. If no one has mentioned an issue with delivering or a need to change the process, then I wouldn't do anything at all.
I have applied Scrum to non-dev teams. I have worked with my wife to implement Scrum in a medical laboratory setting. I have implemented Scrum with a team of individuals that planned and implemented trade shows. And I have worked with an team of people that worked in the personnel department of a company to implement Scrum for some hiring activities. In all of these situations, the Scrum Guide was used to steer us. Once we were able to identify Products, it was not a huge effort to figure out the way to make it work.
If I were in your situation, a difficulty to deliver had been identified, and we were using the Scrum framework from the Scrum Guide, I would work with the Scrum Team to determine the best way for them to work this. There is no "rule" for this so it is all boils down to how the Scrum Team feels they can best manage the work associated to improving the Product.
If I were in your situation using SAFe and a difficulty to deliver had been identified, I'd facilitate a conversation with your team and the Release Train Engineer (RTE) to join in to brainstorm on it. They should be able to come up with something that will make things easier to do and manage since they are the ones responsible for doing the work.
@Daniel Wilhite, I appreciate your suggestions. You're right! I didn't note a problem. I will now. My Agile Practice Manager is concerned that without Jira-logged bug reports, we will miss out on bug metrics. There are two ARTs. The original ART consists of dev teams. The newer ART, non-dev teams. I think he is inclined to have the non-dev ART mirror the dev ART where possible.
I'm trying to be careful about making a false equivalency. Thus, this thread. Maybe bug metrics are not as important in a non-dev team context. Maybe we need different metrics, like number of patches required from vendor or some other measure I haven't yet imagined.
Since the code is being created by a third party, tracking the number of defects is not the same. It could be used to influence the relationship or contract negotiations. But it doesn't mean the same. So the two ARTs would have different measurements of the same metric.
I like your suggestion of different metrics for the non-coding ARTs. Find metrics that are more useful for the work being done by those ARTs.