Newly-discovered bugs and defects are new work. As such, they must be made visible and move through the standard Scrum processes.
Analysis and Recommendations
If there is a defect which [maybe] connected to a previously closed ticket, we create a new one. However, we had a discussion on adding the possibility to reopen a ticket.
If you knew about ...
So many answers to this. It is going to depend on your organization. Someplace like Zappos or Valve is totally self-organized and even self-directed. That said, lets go with your average software development company as your "average" answer.
Then you still have two answers, "now" and "future".
With a 100 developers you're talking a large organization. ...
Create Shared Understanding and Big Pictures Visuals
First, don't panic, agile or not, this is an issue with any delivery that requires coordination.
What you want to look for is tools that help create shared understanding and that help people discuss the big picture. While user stories are helpful, they can still be limiting. I would suggest that you map ...
The thing is that the Scrum meeting shouldn't be technical. There is a meeting called Community of Practice (CoP) and that meeting is for the Scrum Teams to talk about technical problems. So if you can keep the technical discussions out of the Scrum or Scrum-of-Scrums, your managers will be just fine. It is up to the Scrum Master and how he mentors others ...
Don't Give Reports During Scrum-of-Scrums
Your question has a great title that already contains the seeds of your answer, but I think the body of your question obfuscates the issue. You ask (emphasis mine):
How to keep a Scrum of Scrums meeting short and efficient given that reporting on non-technical issues can take a long time?
You are exactly correct:...
We have found it most useful to track the following:
Impediments - who owns them.
Cross-team dependencies - when to expect.
Resource contention - how it was agreed to be resolved.
In addition, you may find this detailed write-up from Mike Cohn of Mountain Goat Software helpful:
How to keep them short: Don't disseminating status or solving technical problems. Do that after.
With 60 people in your Scrum Teams you would likely have between 7 and 10 Teams that all meet individually. It would be impossible for your two Project Managers to attend all of the Daily Scrums and you should trust the Development Teams to bring the relevant ...
[C]ommunication of the requirements leave a lot to be desired.
This is both the core of your problem and your route to process improvement. It seems likely that you are missing Product Owners and Product Backlogs for each team, and do not have adequate coordination at the Scrum-of-Scrums level.
In addition to filling any missing roles and ...
Defining Objectives for Your Scrum-of-Scrums
During the Scrum of Scrums, what should be captured in writing and disseminated to the participants afterwards?
The first step in answering your question is to figure out what your objectives are for the Scrum-of-Scrums. In a related post, I defined the purpose of the Scrum-of-Scrums as a dependency-...
This is a good article (by Craig Larman and Ahmad Fahmy) which describe this problem in real-life situation.
According this article:
Teams should be self-designed (It means people should be allowed to emerge teams on their own).
This process should have facilitator, who will help people to organize themselves in well balanced cross-functional teams.
I encountered the same question, while taking the Scrum.org PSM exam. The short answer is:
You provide the people with the vision - what should the teams be composed for? What are the projects they will to work on? What are the delivery expectations etc
Let the people divide into the teams on their own.
it usually depends on your team process. In our team, once we close the story the QA starts opening up defects. However, the story only gets the QA approval when there is no outstanding sev 1 or sev 2 issues at the end of the last iteration.
I'm not aware of any authoritative answer to this question. In fact, I've seen many. Everywhere I've worked that uses a Scrum of Scrums, it has always been selected as a lightweight approach for teams to synchronize without putting a more robust scaling framework into place.
However, given the fact that the Daily Scrum is not a status meeting, but rather a ...
According to the Scrum@Scale guide it is more about sync and impediment removement:
The SoS holds a Scaled Daily Scrum (SDS). The SDS event mirrors the
Daily Scrum in that it optimizes the collaboration and performance of
the network of teams.
Read more in the Scrum@Scale Guide
Next it suggests a Scrum Master Cycle and a Product Owner Cycle, ...
The cross-team dependency is a known problem on large scale projects. We're running a project with four teams sharing the same platform, and the solution boils down to communicate... a lot.
Specific actions to take into account on how to manage these dependencies:
Avoid cross-dependency as much as possible; it's a no brainer, but sometimes you need someone ...
I understand once you said the user story is done it means there was acceptance from the Product Owner if not from the user and then only the code was merged to your master. If that is a case then from in my view your user story is accepted & closed, any changes should be recorded as new story to the product backlog.
The question about the sense of reopening stories may be the wrong question.
If you want to reopen a story, this may have the following reasons:
1.) You accidentally closed it.
It is completely okay, to reopen it in this case.
2.) The closing of the story was okay, but the result is not satisfying. Do with the story what ever you want - quickly - and ...
In my daily work I used to deal with issue of distributed agile teams and communication within / between teams. I've recently depicted a few (in my opinion) useful hints. Details you find in the post.
This article wraps up several improvements in communication which were introduced in one of the big project I've been working on. To give you a bit of context ...