How to get the right information to the surface during the daily scrum.

Is there a problem with progress not being visible to other members of the team or to other stakeholders? The team is small - if they are collaborating closely with each other, then perhaps a detailed discussion of the work is not necessary. Don't forget that the purpose of the Daily Scrum is inspecting progress and adapting the plan. If the progress is continuously (or more regularly than the Daily Scrum) inspected by the team, then only adaption and associated coordination may need to happen at the Daily Scrum.

Recently, I've noticed that during the daily scrum, not all necessary information comes to the surface

Was it buried during the rest of the day?

What are your observations regarding how well the 3 team members collaborate outside of the Daily Scrum?

Collaboration within the team is fine, but the team looks like it is very prone to scope creep - to make stories bigger and more complex than they were originally intended. Without communicating this with the Product Owner and this results in failed sprints. While we are improving this by improving refinement and setting clearer goals, I wouls like to make the team aware that if they spend more effort than the story is supposed to be, they need to discuss this wiht the PO.

I wouls like to make the team aware that if they spend more effort than the story is supposed to be, they need to discuss this wiht the PO.

While I don't disagree that informing the PO of such changes is a good idea, it is important that we do not think of estimates as fixed commitments. They are, after all, estimates. So the mere fact that a story may require more effort than initially estimated should not be seen as a problem in and of itself. It is the impact that this has on the overall plan for achieving the Sprint Goal that needs to be communicated to the Product Owner.

If communication is high during the sprint, the Sprint Goal is hit, they are completing most of the stories they bring into the backlog and functional software is being delivered per Sprint than their Daily Scrum is sufficient. 

If they aren't doing any of these, than maybe some tweaks could be coached. 

I've noticed as much as Scrum prefers "Working software over comprehensive documentation" we document in JIRA, on the whiteboards, in a burndown chart, daily stand-ups, every two weeks at planning and more. 

Antoine de Saint-Exupery (French Author & Pilot) once said: "A designer knows perfection is achieved not when there is nothing more to add but when there is nothing more that can be taken away."

I try and keep everything as Lean as possible. If they are hitting their goals, let them conduct their meeting how they want. 

Cheers!

I'm going to take a slightly different tact but get to pretty much the same answer as everyone else.

Remember the purpose of the Daily Scrum is not to provide status updates to people outside the team.  It is for the Development Team to plan their work for the next 24 hours. While doing this, impediments that are endangering their ability to meet the Sprint Goal should be surfaced and discussed.  Since I am not directly involved, I can't say whether this is happening.  You state that they are encountering "failed sprints". I'm going to assume that means the Development Team is not achieving their Sprint Goals.  So I see the problem here being it is not clearly understood by the Development Team what is needed to achieve the Sprint Goal and they are not identifying impediments properly.

An impediment does not have to be the inability to access a system or a hardware failure in the build system.  In this case I'd say the impediment is unclear understanding of the problem being addressed and inability to determine impact towards reaching the Sprint Goal. They seem to be impeding themselves by not clearly refining the issues before they start working.  

Another concern for me, given the assumptions I have made, is that it isn't clear whether the Scrum Team fully understands the purpose of the Sprint Goal. Or for that matter whether they are even using Sprint Goals since you never mention it.  A Sprint Goal is used to focus the team on work that will achieve the needed results that leads to value delivery.  Goals provide direction, boundaries and shared understanding.  If you decide to go on a trip but do not decide where you want to go, how do you know if you are close to getting there?  Or when you need to turn around and come home? Don't let the team wander aimlessly for Sprint after Sprint. Help them determine and proceed towards their goals.

 While we are improving this by improving refinement and setting clearer goals, ...

You seem to be doing the right thing. Both of these activities will help team focus and allow them to realize how the work they do impacts the needs they are trying to fulfill.

I wouls like to make the team aware that if they spend more effort than the story is supposed to be, they need to discuss this wiht the PO.

I suggest you approach this differently. Why not make the entire Scrum Team aware that no one will ever know how much effort a story is supposed to be until the story is completed? Help them focus on the fact that the amount of work will most likely change once work begins. It could become less or more but only taking action will make it possible to determine that.  Aid the Scrum Team in learning how to adapt and respond to changing conditions and new information.  Help them realize that the entire team is accountable for the work done to solve needs and everyone has parts to play. They need to be aware of how each role depends on the others in order to accomplish their shared goal. Also refrain from saying that they are failing because it sounds like they are trying to learn from their difficulties.  I always tell people that the only failure is when you choose not to learn from difficulties or unexpected results. From what you said, the team is trying to improve based on the situations they have encountered.  That is a sign of a successful team in my opinion.