Background I am a scrum master for a team consisting of a PO, team lead and 3 developers. The team lead and 3 developers are off-shore in a totally different timezone. The PO is in the same office as me.


  • Backlog grooming meeting is not working as they want to design the solution during the meeting. They want to estimate only when they understand and have largely designed the solution
  • They want to take 'breaks' to discuss things in their native language
  • They don't want to create user stories themselves which is fine, but they don't agree with the way the PO splits the stories either.


  • How do I facilitate an effective planning/grooming/refinement/triage meeting effectively given this scenario?

I have taken a stab at solving my problem and this is what I came up with:

  • The PO and I do a user story mapping session just us 2 and come up with an initial set of user stories, and activities and then using the planning meeting to ratify and estimate with the team.
  • Would you say your stories are 'technical' in nature, i.e. they include some implementation details? Also, is there management pressure on the team to estimate accurately? Aug 7, 2017 at 21:12
  • 1
    @BarnabyGolden the stories which are created by the PO are not, however the team does create stories as well which are more like technical tasks yes. I am trying to discover if they is management pressure I suspect there is.
    – TheLearner
    Aug 9, 2017 at 7:05
  • You said that "they want to estimate only when they understand". Can you please tell what is the problem you see in it? And how do you expect them to estimate accurately if they do not fully understand the problem? Aug 10, 2017 at 18:31
  • Ok so you've taken those words out of context. If you read the whole thing you will see that I am referring to having a whole understanding of the solution before estimating.
    – TheLearner
    Aug 11, 2017 at 4:37

5 Answers 5


TLDR: Talk to the Team.

Keep in mind the four core principles of the Agile Manifesto, particularly the very first one:

Individuals and interactions over processes and tools

Of the four principles, the first is the only one that directly suffers from having a distributed team. And from your question, it seems like you're trying to solve this problem by implementing a process. If you look again at the first principle, it should become apparent why this is problematic.

With that thought in mind, let's walk through your three issues:

Backlog grooming meeting is not working as they want to design the solution during the meeting. They want to estimate only when they understand and have largely designed the solution

Best, I think, to first break this down into why this is a problem. What is the purpose of your Backlog grooming meeting? And, importantly, find out what your Development Team views its purpose as being, as this may be different. Is it just to follow your procedure, as mandated by... your procedure? If so, then the issues become apparent. Is it some other, actually useful purpose, for example, as @Mark C. Wallace suggested, to develop plan, priorities, and/or architecture? If so, bring your concerns to the Development Team as to how this purpose is not being met, and ask the Team for suggestions on how to fix it. Any suggestion created internally, or collaboratively, is going to be accepted far more readily than one imposed on the Team from above.

They want to take 'breaks' to discuss things in their native language

Other than getting a new Team that speaks English, there are really only two solutions to this. Either the Team improves their English (you could, for example, send them to a class of some sort, ideally on Company dime). Or you could improve your (insert foreign language here). Or both.

They don't want to create user stories themselves which is fine, but they don't agree with the way the PO splits the stories either.

As always, collaborate. Find out why the Team doesn't like how the Product Owner is splitting the stories. Maybe they're wrong. Maybe the PO is wrong. Maybe they're both wrong. The only way to find out is an open discussion, with no pre-existing bias. One goal you should probably approach is obtaining a shared understanding of how stories should be sliced. One approach is simply to cut them as small as possible while still on their own being able to provide business value. Another approach is to follow the INVEST mneumonic.


Here are some problems as I see them:

  • Natural language barrier
  • Disagreement over appropriate slicing of work
  • Disagreement or ambiguity over the desired outcome of "backlog grooming"

It sounds like you, as the Scrum Master, now have a few responsibilities:

  • Guide the team to a more detailed shared understanding of what desirable slicing looks like
  • Get to the bottom of what the outcome of the grooming session should be. If the team feels incapable of estimating without a detailed plan, why is that? What would happen if you didn't require an estimate at that point?
  • The team should make its expectations about language more explicit. Maybe you need a working agreement over when to use which languages.

I suspect that any work involving stories which you personally do alone with the PO won't lead in the right direction; the team needs to find the right balance of PO and development team.

  • It feels like the right answer is by the Scrum Master being more forceful in the meetings to get the team to stick to the "agenda" of sizing the stories as written (or explaining the issue with the story as currently sliced)
    – Andy L
    Aug 9, 2017 at 11:44

Sounds like you are moving away from agile. Because the team isn't following your process expectations, you are proposing reducing their role to that of ratifier. That will undercut their engagement.

I would go the other way. Ask the team how to solve the problem. If we don't groom the backlog, we will always be looking at trees not forest. If we do design in the backlog sessions (instead of the intended activity of the backlog session), we will drown in technical debt. Based on that, how can we, as a team, change our behavior to resolve the problem?

  • "If we do design in the backlog sessions, we will drown in technical debt." Why? What's the cause-effect there?
    – Sarov
    Aug 9, 2017 at 13:45
  • If you don't manage backlog in the backlog sessions, aren't you trapped in eternal reaction, with no plan, no priorities and no architecture? How can you dig out of debt if you don't know where you are going?
    – MCW
    Aug 9, 2017 at 13:57
  • 1
    If I understand correctly... so your statement wasn't 'if you do design', so much as 'if you focus on design rather than grooming'?
    – Sarov
    Aug 9, 2017 at 14:00
  • Precisely. If you permit design to displace planning....(will edit onto question when I am not typing on a cellphone.)
    – MCW
    Aug 9, 2017 at 14:14
  • Ah, I see. That makes sense, then.
    – Sarov
    Aug 9, 2017 at 14:16

Some say that Agile doesn't work without team being in one place, I'd say in order for Agile to work there should be a good process established. Keep in mind that Agile is unique to most of the teams, as they got different backgrounds behind them.

Most teams end up hybridizing the approaches, making scrumbans, or part of the workflow for reqs eliciting / stories drafting is done in iterative waterfall. Since scrum / or agile as a whole is not a silver bullet (esp. given that you'll have deadlines sometime).

We also got a remote team, and came up with the following hybrid approach, where:

  1. BA / PO drafts the stories for preliminary analysis, since they communicate with clients

  2. Later on, they sit and discuss (we got 9-13 hours difference between team members) the plan for the next feature with development team. There is a moderation always, when it comes to meetings, so that noone's out of scope. That early drafting saves time, since whole story is not written out, thus if developers torpedo the idea, time was not wasted.

  3. Decomposition is done together with devs, cause decomposed bits are done by developers. So the last word is their's (given that they are willing to collaborate). BA / PO's job is to make sure that issue is laid out clear enough

  4. So after the whole team approves and estimates the decomposed bits (we don't practice story points), we move stories to Ready for Implementation and start working on them. We don't use sprints, but have a Kanban board, so not sprint planning is needed here, as well as iterations.

Maybe this will help you a little :) Lang. barrier is unsolvable, until your devs get to some english camp to speak and understand fluently, but for 90%of discussions, simple english is always enough to get the notion of the story and add notes on implementation.

  • This is interesting and I think its the most feasible for me to attempt. Would you mind elaborating the steps a bit i.e. what does the output of the BA/PO look like and what does the finalised bits look like
    – TheLearner
    Aug 9, 2017 at 12:54
  • Well, first of all we got separated processes for IDEAS (tickets that are not yet ready to be implemented) and Development. The workflow for IDEAS is the following (spacekimo.files.wordpress.com/2017/07/pre-dev-workflow.png). You can read it in my blog (I've barely touched that topic, but it gives a bit of an understanding <kiniabulatov.com/2017/07/17/why-we-finally-ditched-scrum starting from IDEAS board section till Development Board section>. Aug 10, 2017 at 6:35
  • Basically, we got a few stages: Preliminary Analysis (goals and overall approach, what benefits does this feature give us) -> Sign Off (by stakeholders and responsible ppl, may be by teamleads as well) -> Detailed Analysis (at this point you get wiki page with feature desc., goals) -> User Stories & UX (formalizing and decomposing, together with dev team) -> Ready to Schedule. Development Team gets in, when we have Detailed Analysis step. Cause we start to discuss implementation and general warehouse processes there, see what underlying architectural changes are there to jump over. Aug 10, 2017 at 6:42

IMO, its quite tricky to get Agile to work unless there is a team. One team working in one room in one time zone. You cannot control the timezone but technology can help with creating a virtual one room.

You should definitely try ensuring you have a web cam in each office that are on during working hours and see if you can at least work 4 to 6 hours together. If this is not possible, quit Scrum and go old school.

PO will have to document the requirements in detail. Try using a combination of use cases and wireframes. The current Scrum Master will revise this and ensure its detailed enough before submitting it to the offshore team.

You can still ensure PO is available on short notice if the dev team need clarification. You can even break the project into chunks and ask the dev team to release stuff monthly at most.

This answer may be controversial but I have never seen teams that cannot work together, at least through a web cam, succeed with agile. Agile teams sre like army units or football teams. You do not have a football team or army unit if half of them are offshore.

  • I hear you! I have heard a couple of people say the same or say at least that its significantly harder to achieve an Agile way of working. We do tend to work for about 2 hours together. We do a 'standup' and a grooming meeting together.
    – TheLearner
    Aug 9, 2017 at 7:17
  • 1
    I disagree, I'm working with a team based in Dallas Texas, Wisconsin, and 3 different Polish sites as well as an office in Dublin. Everyone works from home except the Irish Scrum Master. It works. and a lot of the issues can be resolved by good collaboration tools like Skype for business & a webcam!
    – Andy L
    Aug 9, 2017 at 11:47
  • I wrote: "This answer may be controversial but I have never seen teams that cannot work together, at least through a web cam, succeed with agile." Your use of Skype and Webcam seems to fall under what I feel is the minimum requirement. Just wondering, why is the poor SM not working from home as well :?
    – Muhammad
    Aug 9, 2017 at 13:46
  • "Agile can't work unless there is [...] One team working in one room [...]" and "use of Skype and Webcam [...] is the minimum requirement" seem to contradict each other. You may wish to change your wording - it's not so much that they can't work as it adds extra requirements in order to be able to, right?
    – Sarov
    Aug 9, 2017 at 14:30
  • OK. Pride swallowed. I did the edit :)
    – Muhammad
    Aug 9, 2017 at 16:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.