If you read the Agile Manifesto and its principles, you will see wording like:
- Individuals and interactions ...;
- Customer collaboration ...;
- Business people and developers must work together daily throughout the project;
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Your problem revolves around these things. Your customer doesn't seem properly involved for an Agile project. If your team has questions and the customer is not around, the responses get delayed. The delays then cause a dependency for development work. Unmet dependencies then turn into blockers.
When work in the sprint gets blocked, and you are not expecting answers quickly as you mention, you have two main options:
- The first is to work on something else, something on which you are not blocked and don't need to wait for answers.
- The second is for people to stay idle while they expect an answer. Basically the story is blocked and you just wait until you get the information you need.
The first option seems the most reasonable, but it may have some serious side effects. If you can work on things that bring value then that's ideal, you can do that. But if you work on stuff that doesn't bring the most value, then basically you work on stuff that just happens to be possible to work on. Any stuff.
For example, if you have an ordered list of items in your backlog then you work from the top. But if the first, second, third and forth items are blocked and awaiting responses from the customer, you might work on, say, the fifth. But the fifth is not the most important, the first four are. So basically your prioritization of work gets all messed up. You will eventually turn your backlog into Swiss cheese, full of wholes, while you work on whatever you can that you are not blocked on.
If you then get a response on a blocker, you might have to drop what you are doing and need to start work on the more important things. This causes context switching which is inefficient. Even more context switching when you get back to what you were working on before you got unblocked on the important stuff. This causes frustrations in the team and really messes up your sprints because you can't really plan properly as at any moment you can receive an answer you were waiting for. You might also continue your sprint and work on the stories that got unblocked in the next sprint, but you will just be sliding stories from one sprint to the other.
Now to the second option.
To avoid the issues with the first option, your team could just wait for the information. If they get blocked, they get blocked. That's it. If a story is not properly defined and needs extra information, then they don't start work on it. Basically you try to stick to building what brings most value (i.e. from the top of the backlog) and pause if something is blocking you. This way you don't turn your backlog in Swiss cheese full of wholes and you don't make a mess of prioritization, planning, or of the application itself.
But of course, the second approach looks inefficient because people are paid to do nothing but wait. And here comes the solution to your problem. You need to make your customer aware of this. Communicate transparently that people are idle while blocked by lack of information. Have your PM involve and push for the customer to unblock you. Coach the customer on how to become more involved. Get them more involved.
The second approach is better because it will bring more benefits in the long run. The first approach is worse because it gives you the impression you are doing something now, but in the long run you will just make a mess of things.
Work on getting your customer more involved. If they don't want to get more involved, then they must accept the fact that people won't be able to work at full capacity because they are awaiting answers.
