Two feet on the ground (Refining)

This is what we want: we want the user story under control
This is what the PO wants: the PO want the user story in the sprint and finished in it.

Theory vs. reality

There are a few things I need to explain or bring up before we go further.
Most of the pitfalls we encounter are these:

• The user story is bigger than we thought
• The acceptance criteria grew throughout the sprint
• We came across things we didn't think of at first
• We needed more resources than we thought.
• The user story actually became clear in the sprint itself.
• The PO thought different about the finished user story than the developer

All these things happened to me and the teams I worked in. Of course there are uncertainties along the way but most of them can be taken away from the sprint easily.
Why was the user story bigger than we thought, how is it possible that we didn't predict the resources we actually needed? It's all in our own hands. I'll tell you why these things happen. The familiar workflow a feature is taken in and out the sprint is this:

• First, the customer wants something
• The PO takes a look at it and writes the user stories
• The user stories are in the backlog so they eventually are automatically taken into the sprint
• The team predicts/pokers its story points
• The team develops and tests and the user stories are done.

This looks like a logical workflow, I think to all of us, but it's not. It's too static to be applicable in reality. This doesn't work! What you need is more collaboration. This workflow comply if we were robots. But we are human and I'm glad we are. And humans don't act static. They surprise us on every occasion. And there are some hidden features within humans;

Humans and interactions

We all want the people to know that we fully understand the user story cause we are supposed to know everything about the program and we don't want to look stupid. We always tend to act better than we are.
And what is also in our blood: we want to help the customer, and preferably as quickly as possible. We don't want anybody waiting for us.
We don't want to let the PO know that we don't know enough of the current situation in the software. We don't want him (or her) to know that it's pretty hard to understand what the user story fully implies. We don't want to say 'no' to the PO cause we love to say 'yes'! And we do. We always say 'yes' to the PO.
We don't like to look dumb or inexperienced. But when we are not feeling dumb and we are experienced, we lack to see all of the different angles of the story. We don't want to sit next to the tester to understand what he wants to test, because we can do that ourselves good enough. These are the most common human behaviors we encounter.

Use your humanity!

Make sure you discuss a user story before the PO decides it must be picked up in the next sprint. How? Ask questions! Ask a tester if he can test it. When he says 'What the hell' the story is over. If he says 'I think so' try to figure out what he needs to be confident. Define tasks to clear things up for him. If a developer isn't certain about the code, ask him why. Ask until there are no questions that impede the story to be clear. And I really mean the story and not the implementation. The trick to find the doubts is listening. Listen to the conversation that is being held. If you here 'I think' or 'probably' or 'If this' or 'what is' or 'who is' then there's a threshold in the story. All these questions have to be answered first to eventually able you to estimate the amount of story points. Do not try desperately to answer all questions with the purpose to eliminate all of the doubts. There can be questions left unanswered, as long as you all got a good feeling about the story and you know exactly what the PO wants and why the customer wants it. A good thing about fire some questions is that you KNOW that there are questions about it and you take it into account.

The ultimate computer, so far.

Let's take it a step back shall we? If there is a project for example coming up next month, you really need to know what it is. Let the PO present the big picture. It helps him, because he presents it and he never had before, and that helps him to understand it better. But last not least it helps the developer. You know the brain is a beautiful piece of equipment. What we don't realize is that when we are presented and familiarized with the project, our brain is without knowing processing the information in our head. It strikes us with ideas on moments we don't expect it to happen. It is a computer unconsciously rattling on a background process. So if you are planning to sit together again on the project, it feels like you've had a good night sleep on it. You become more alert and ask the right questions and maybe the PO let you break down the project with him or her into features and user stories together.

Summarized 

A developer team needs all the individuals within the team, the team needs the PO and the PO really needs the whole development team.