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 ...
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 ...
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. ...
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 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 ...
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.
[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 ...
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.
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 ...
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 ...