Tweeted twitter.com/StackProjects/status/1026211719343992832
3 Added "scrum-master" tag
| link
2 Fix grammar, expand acronyms
source | link

We are team of a 7 developers, 2 interns, one UXuser experience specialist and a QAQuality Assurance member. The team is usually dealing with new clients. Not all members are involved in the same project,project; usually there are two parallel clients with 3 or 4 FTEsFull-time equivalents assigned. Few members are involved in both projects at the same time and one or two are taking care of the interns.

For each project we have separated backlogs, and ceremonies scheduled at different times. We try not to overlap these meetings so that the common members can attend both. This is going well.

However, the entire team is doing the daily meeting (DM) together.

So we start with Project A, the members involved with the Project A present their progress, impediments and what they intend to do for the rest of the day and once this is finished we get to the Project B. Then the interns will present their progress to us.

There are several problems with this. The members involved solely in one project have no context about the other project, because they don't participate in the other meetings, neithernor in the development. They recognize some terms, ideas, and verbs, but still couldn't really comprehend what the other members are talking about. Visible signs of boredom start to appear, like checking the phone, impatiently stepping fromfrom one heel to another, sudden eye-rolls or not very polite smiles. This puts pressure on the other team to hurry up their DM and thus they are not really focusing on the actual impediments or inon the synchronization between the devs that are working on a certain story/task.

The DMs don't take more than 10-14 minutes for both projects together.

On top of that, Project A has a different meeting with the POProduct Owner (PO) half an hour after this meeting inon certain days inof the week (M, W, F). This meeting is nothing more than a status update to the PO, but it doesn't really help the project. We agreed today that at least in these days not to have both and to have only the one with the PO and discuss here the usual DM. The PO gets more context thus.

The arguments for keeping the DM with the entire team are twofold. First, the fact that, well, we are a team and this is the only moment when we are all together so we use it to boundbind the team. The other is so that everyone knows what's happening, on what each person is working on, what the other project is about or what support items appear from older projects (not too often though).

I have only 1,.5 years experience with SCRUMScrum and am not sure how we should proceed with this. I just feel like having a DM per project is better, but I get a strong NO'NO' against it from key members, some believing that I want to try to split the team.

How should we deal with this?

We are team of a 7 developers, 2 interns, one UX specialist and a QA member. The team is usually dealing with new clients. Not all members are involved in the same project, usually there are two parallel clients with 3 or 4 FTEs assigned. Few members are involved in both projects at the same time and one or two are taking care of the interns.

For each project we have separated backlogs, ceremonies scheduled at different times. We try not to overlap these meetings so the common members can attend. This is going well.

However the entire team is doing the daily meeting together.

So we start with Project A, the members involved with the Project A present their progress, impediments and what they intend to do for the rest of the day and once this is finished we get to the Project B. Then the interns will present their progress to us.

There are several problems with this. The members involved solely in one project have no context about the other project, because they don't participate in the other meetings, neither in the development. They recognize some terms, ideas, verbs, but still couldn't really comprehend what the other members are talking about. Visible signs of boredom start to appear, like checking the phone, impatiently stepping from one heel to another, sudden eye-rolls or not very polite smiles. This puts pressure on the other team to hurry up their DM and not really focusing on the actual impediments or in the synchronization between the devs that are working on a certain story/task.

The DMs don't take more than 10-14 minutes for both projects together.

On top of that Project A has a different meeting with the PO half an hour after this meeting in certain days in the week (M, W, F). This meeting is nothing more than a status update to the PO, but it doesn't really help the project. We agreed today that at least in these days not to have both and to have only the one with the PO and discuss here the usual DM. The PO gets more context thus.

The arguments for keeping the DM with the entire team are the fact that well, we are a team and this is the only moment when we are all together so we use it to bound the team. The other is everyone knows what's happening, on what each is working on, what the other project is about or what support items appear from older projects (not too often though).

I have only 1,5 years experience with SCRUM and not sure how we should proceed with this. I just feel like having a DM per project is better, but I get a strong NO against it from key members, some believing that I want to try to split the team.

How should we deal with this?

We are team of a 7 developers, 2 interns, one user experience specialist and a Quality Assurance member. The team is usually dealing with new clients. Not all members are involved in the same project; usually there are two parallel clients with 3 or 4 Full-time equivalents assigned. Few members are involved in both projects at the same time and one or two are taking care of the interns.

For each project we have separated backlogs and ceremonies scheduled at different times. We try not to overlap these meetings so that the common members can attend both. This is going well.

However, the entire team is doing the daily meeting (DM) together.

So we start with Project A, the members involved with the Project A present their progress, impediments and what they intend to do for the rest of the day and once this is finished we get to Project B. Then the interns will present their progress to us.

There are several problems with this. The members involved solely in one project have no context about the other project, because they don't participate in the other meetings, nor in the development. They recognize some terms, ideas and verbs, but still couldn't really comprehend what the other members are talking about. Visible signs of boredom start to appear, like checking the phone, impatiently stepping from one heel to another, sudden eye-rolls or not very polite smiles. This puts pressure on the other team to hurry up their DM and thus they are not really focusing on the actual impediments or on the synchronization between the devs that are working on a certain story/task.

The DMs don't take more than 10-14 minutes for both projects together.

On top of that, Project A has a different meeting with the Product Owner (PO) half an hour after this meeting on certain days of the week (M, W, F). This meeting is nothing more than a status update to the PO, but it doesn't really help the project. We agreed today that at least in these days not to have both and to have only the one with the PO and discuss here the usual DM. The PO gets more context thus.

The arguments for keeping the DM with the entire team are twofold. First, the fact that, well, we are a team and this is the only moment when we are all together so we use it to bind the team. The other is so that everyone knows what's happening, on what each person is working, what the other project is about or what support items appear from older projects (not too often though).

I have only 1.5 years experience with Scrum and am not sure how we should proceed with this. I just feel like having a DM per project is better, but I get a strong 'NO' against it from key members, some believing that I want to try to split the team.

How should we deal with this?

1
source | link

Two clients, one team, should we still have the standups together?

We are team of a 7 developers, 2 interns, one UX specialist and a QA member. The team is usually dealing with new clients. Not all members are involved in the same project, usually there are two parallel clients with 3 or 4 FTEs assigned. Few members are involved in both projects at the same time and one or two are taking care of the interns.

For each project we have separated backlogs, ceremonies scheduled at different times. We try not to overlap these meetings so the common members can attend. This is going well.

However the entire team is doing the daily meeting together.

So we start with Project A, the members involved with the Project A present their progress, impediments and what they intend to do for the rest of the day and once this is finished we get to the Project B. Then the interns will present their progress to us.

There are several problems with this. The members involved solely in one project have no context about the other project, because they don't participate in the other meetings, neither in the development. They recognize some terms, ideas, verbs, but still couldn't really comprehend what the other members are talking about. Visible signs of boredom start to appear, like checking the phone, impatiently stepping from one heel to another, sudden eye-rolls or not very polite smiles. This puts pressure on the other team to hurry up their DM and not really focusing on the actual impediments or in the synchronization between the devs that are working on a certain story/task.

The DMs don't take more than 10-14 minutes for both projects together.

On top of that Project A has a different meeting with the PO half an hour after this meeting in certain days in the week (M, W, F). This meeting is nothing more than a status update to the PO, but it doesn't really help the project. We agreed today that at least in these days not to have both and to have only the one with the PO and discuss here the usual DM. The PO gets more context thus.

The arguments for keeping the DM with the entire team are the fact that well, we are a team and this is the only moment when we are all together so we use it to bound the team. The other is everyone knows what's happening, on what each is working on, what the other project is about or what support items appear from older projects (not too often though).

I have only 1,5 years experience with SCRUM and not sure how we should proceed with this. I just feel like having a DM per project is better, but I get a strong NO against it from key members, some believing that I want to try to split the team.

How should we deal with this?