I work in an enterprise Software Company in Asia. We have a weekly meeting with the product team.

During the meeting, we discuss and groom the upcoming stories to ensure that the product and development team are on the same page.

The problem is that almost ALL of the members here are 100% silent throughout the meeting. All the communication happens between product team and only one of the team members here - he is the team lead. The rest are physically present, but otherwise do not participate.

To improve efficiency, my manager has asked us not to attend this planning meeting anymore and continue our development. The team lead alone will continue attend the meeting.

I personally think, there should be some other ways to address this problem instead of just asking people to stop attending the meeting.

How should I share this concern with my manager? And what kind of solution can I propose to him which brings the momentum and participation into our meetings?

  • 36
    What actual problem are you trying to solve here? In most cases, if you tell a dev team "fewer meetings", you'll get a happier dev team :-) Jul 10, 2017 at 5:52
  • 8
    What kind of things do you expect them to say? If they don't have anything to contribute, why would they say anything (and why should they be there)? If you expect them to have something to contribute at any given time, why not just ask for their feedback directly? Jul 10, 2017 at 6:49
  • 19
    Sounds like someone in management has heard of scrum and agile, like the idea, and is trying to get the team to adopt it without a) getting them to self-organise their way in to agile and b) adequate education/training on what's expected.
    – HorusKol
    Jul 10, 2017 at 9:41
  • 6
    This might be a cultural problem. I'm not an expert, but as far as I know, workplace hierarchy has much less weight in the USA than in some asian countries. So asian employees are much more reserved.
    – Chris
    Jul 10, 2017 at 10:51
  • 9
    This seems like a "cultural difference", not a "scrum problem". They team members all learned what the proverb "A nail that sticks out of the wood will be hammered down" means when they were young children. Perhaps the OP doesn't! It's also a cultural thing in the middle east - if you get a peer group together to solve a problem, they may spend 95% of the meeting time discovering who knows most about the subject, and then unanimously agree with whatever he/she says is the answer, with no real discussion of the issues at all. That's not the way things get done in the USA or Europe!
    – alephzero
    Jul 10, 2017 at 14:44

7 Answers 7


I've noticed that it's quite common for these grooming sessions to only involve one or two people actively. Generally speaking there's a few folks who enjoy discussing talking requirements and a few who just want to be told what to build.

Your manager is on to something by saying it's not efficient for everyone to be there. Not everyone needs to be at a grooming session; as long as it's roughly clear to everyone what to do when it comes time to do the actual Planning session. It's a team effort, so whomever knows well, can always explain to the others.

What we've done in the past is rotate the person/people who attends the grooming. It is almost never productive to pull in the whole team; one or two people will ask the same questions, point out the same things that need more information, etc. And nothing discussed is going to be built that week anyway.

Ask your team who enjoys going to the meeting and talking about requirements and who doesn't. Then start sending the people who enjoy the meeting to attend it alone and let them take a few minutes (or more, if neccesary) at the end of the meeting to share what they've learned with the team. Most likely you will end up with the same level of understanding and clarity, at a fraction of the cost.

  • I'd add that if the OP does have specific concerns, they should consider how they might be monitored to see if there are actual downsides. For example, are you worried about more time spent on communication after the meeting? More changes to the sprint after the meeting? Those kind of things can be metricized, to an extent. Jul 10, 2017 at 17:24

You are not using the Scrum terms, so I'm guessing you are not actually doing Scrum. My first advice would be to get a good book or better yet trainer.

Your product team is what is called Stakeholders. And indeed, talking to the stakeholders finding requirements is not the Development Teams job. The Product Owner talks to the stakeholders.

The Product Owner then talks to the Development Team in a grooming to refine the stories and make them either SMART (Specific, Measurable, Achievable, Relevant, Time-boxed) or INVEST (Independent, Negotiable, Valuable, Estimable, Small/Scalable, Testable) or whatever acronym is up to date.

You should have a Scrum Master that you don't mention. And there is no team leader in Scrum. He seems to be doing what the Product Owner should be doing, so maybe that's just a mislabeling?

So yes, your manager is right. Your Product Owner should be in that meeting, for the dev team it's just a waste of time (as demonstrated by their non-action). You should have another meeting regularly (normally called "grooming"), in which the Product Owner shares his insights from the first meeting with the team and where the team can ask questions and discuss the technical details as well as make an estimation.

  • The grooming should be almost continuous as new stories are added by the product owner - although that's not always possible, and it is helpful to have the scrum master (or senior dev if SM not appointed) help. There still should be a sprint planning meeting at the start of the sprint with the development and product owner (not stakeholders) where the developers all get to pitch on story/task points.
    – HorusKol
    Jul 10, 2017 at 9:38
  • 3
    Having someone with technical knowledge talk to the stakeholders, even is it only a Functional Designer, is incredibly useful.
    – Weckar E.
    Jul 10, 2017 at 10:04
  • 3
    I like this answer even better than mine.
    – Erik
    Jul 10, 2017 at 10:23
  • 4
    @WeckarE., you are correct, and it is not a discrepancy with the answer. nvoigt is talking of roles. If the product owner does not happen to have technical knowledge, then it is absolutely fine and appropriate to have one or two guys from the team in the meeting to provide such. They act more as advisors to the product owner. The point is that you only need select few, and certainly not the whole team.
    – AnoE
    Jul 10, 2017 at 12:12
  • @Erik, so do I, but your answer was accepted only 1 hour after the question was posted. If there was a vote, I'd vote for a 24h minimum time span before acceptance was possible...
    – AnoE
    Jul 10, 2017 at 12:14

There is a key point being missed in the answers - the company is in Asia. There is a cultural component that needs to be called out and separately considered. Many asians are uncomfortable voicing an individual opinion when in a group.

As the practice lead / scrum coach / agile evangelist, you need to ensure the development team know that it's a safe environment to comment and offer commentary to the "Product Team". That they won't "lose face" or be thought to be criticising the Product team.

You'll need to change / work on the cultural norms in the development groups before the agile practices become natural. Note that it's not just the development group that needs to change, it's also the Product teams, and the management teams. If the devs take up the Agile manifesto they will question and feedback to Product and Management and those groups have to respond in the Agile manner. If the Product and Management groups don't change in their expectations, then scrum isn't going to work.

  • 3
    This should be the correct answer. Asians are different then us Westerners and treating them like another Westerner is going to fail. Find their strengths and attempt to leverage them. If you want to implement change, be sure to do it gently.
    – mj_
    Jul 10, 2017 at 14:21
  • "Asian" and "Western" programmers are all identical, in that they know that meetings are an utter waste of time.
    – Fattie
    Jul 11, 2017 at 12:01

To me, this sounds like a sensible decision on the part of your manager. Grooming the product backlog is formally a task for the product owner, although in my experience is generally helpful to have someone technical involved in the discussion as well. Don't force the rest of the team into a meeting for the sake of having a meeting.


Your manager is right. If scrum done "as it should be" does not fit your employees office culture, then you shall not do scrum "as it should be", but adapt the way it is done. Scrum is supposed to be an agile method, which means you adapt the process to the context, not the reverse.

People are part of the context. They seem not to fit culturally with that meeting, as it is set up. Therefore, that meeting has to be changed.


There appears to be something missing here. What are you discussing in your scrum meetings?

You should be making project estimates in the meetings, instead of handing out schedules. The most accurate estimates are done by people doing the work. Sometimes these meetings try to gather people who are experts in the project, so they can point out an inaccurate estimate or help someone who can't estimate.

Sometimes someone has no idea how to do something they're assigned to for that sprint, and someone else on the team should be able to point that out.

Some people are better at communicating in writing than in person. Then these meetings should probably be done online, on a team communication tool like Slack.

Sometimes people are shy or afraid of conflict. Then most of the communication should happen with the team lead and the rest of the team in one-on-one meetings. These one on ones can be extremely effective and many established companies insist on them.


Find out WHY the people are not talking. Are they afraid of repercussions if a manager doesn't agree with them? Is there a blame culture and if their statements lead to problems it can lead to them getting punished (fired, even)? Is it simply a tendency (which I've noticed a lot) to sit quietly, waiting to be told what to do by people in authority, mind that this is in part linked to the other possibilities? Do they lack domain knowledge or technical knowledge about anything but a very narrow part of the system?

Find out what prevents people from providing input, then do something about that. And that might be painful for some, especially if it's a cultural thing in the company and people in power have to change their way of doing things.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .