Am I doing my user stories right? The team aren’t getting it.

Post-it note and pen

Recently I was working with a BA to explore why the user stories she is creating are not being followed by some of her team.

About the Team

She is in the situation many people in large organisations are in. She is in an Agile team where part of the team is co-located with the users in the UK and part of the team (frequently developers) are members of another organisation and located in another country. Commonly referred to as offshore partners.
In her project she is writing stories then discussing with her offshore team to explain them. She gives the team as much opportunity as possible to ask questions and say where they don’t understand. But they are not fulfilling them, They are overworking the solution and doing things not in the story.
She is spending many hours going back re-writing stories and re-explaining them, as her belief is that the problem is she isn’t being clear enough. All she has to do is explain them better and they will understand. So she came to me, in some frustration to ask me to review her stories.

And the stories?

I reviewed the stories she had written; the clarity of the language, the size, the acceptance criteria, the features and epics they were part of.
They were excellent. Exemplars of good practice. But still, the team was not fulfilling them. They were overworking the solution.
“Maybe”, I suggested, “the stories aren’t the problem.”

What matters to your team?

I asked her, “Have you considered that they are not following them for another reason? What do you know about their company?”
We all work on assumptions. One big assumption we have is that other people see the world in the same way that we do. It is an assumption that, for the most part, works. It allows us to interact easily with people on a day to day basis. However, if you are having difficulty communicating well with someone it is worth challenging this very basic idea.
While you are all part of the same team, the measures of success of an offshore partner are not, necessarily the same as that of your company. If some of your team have other priorities then they will fulfil those in preference to team goals.
So we discussed a number or areas. What is important to them? What are they being measured by? Was Agile working written into the contract in the first place? What are the SLA’s?

Could it be cultural?

The offshore team is based in India and working across cultures can be tricky. Companies have cultures, countries have cultures.
I showed her my new favourite book on working across cultures, Erin Meyer’s The Culture Map and we had a look at a couple of the areas where UK and Indian cultures differ.
erin meyer the culture map book cover


In the UK we build trust at work based on competence and reliability at work. We may work very closely with someone during a project, and then barely see them once we change projects. In India trust is built more slowly through getting to know someone on a personal level for example by having meals with them and attending social occasions outside of work. It is hard building mutual levels of trust and respect over a teleconference


Disagreeing with a client is hard. In the UK, we do everything we can not to say ‘No’ to a client but within teams we value different opinions about how to get things done. In Indian culture, disagreement is seen as negative for a team and adversely affecting relationships. Offshore team members are going to find it very difficult to challenge you, their client, in the first place. Being expected to do this is a group environment makes it harder.


The thing that worked for this BA was taking discussions out of the group environment and into one-to-one conversations. That took the pressure off people who didn’t want to disagree in a team environment and she could then get to any underlying issues. She has now changed some of the ways the team works and things are improving.
The lesson here is that, if something isn’t working don’t keep on trying to improve your current way of working forever. Different is not a synonym for wrong and it is good to take a step back and look for a different way of addressing your issues. A fresh approach can bring surprising results.

Get ‘9 Cognitive Bias Project Hacks’

Enter your e-mail for the free download and (very occasional) notifications of new articles

I will never give away or sell your details. You can unsubscribe at any time.

This entry was posted in Agile, Behaviour and tagged . Bookmark the permalink.

Leave a Reply

Your email address will not be published.