First questions to ask yourself are:
- can I aford to lose this developer?
- will I have a hard time finding a replacement if you lose him?
- what impact will his behaviour have on the other team members/project if this is allowed to continue?
Regarding the third question, from experience I can tell you that his behaviour will get worse and that inevitably some of the other team members will start behaving in a similar way. Think about it. Tom is slacking off and he is not confronted about it. This creates an indirect incentive for him to slack off even more just because he can. At some point, others will figure out that Tom is slacking off and nothing happens to him, so they figure out that they could step down a gear also and work less hard.
So you have to do something about it. And here, the first two questions above become important.
You need to tell Tom what you noticed. Tell him you know he can do better and you would appreciate it if he does. From personal experience with things like this, I can tell you Tom will not all of a sudden say "Oh gosh... I wasn't aware of me doing this. Thank you for bringing it into my attention. I will imediatelly start behaving differently". Won't happen.
What's likelly to happen are things like this:
- Tom will start working more but at the same time he might start looking for a job somewhere else and leave. His behaviour most likely isn't developed in your team, he possibly picked it up somewhere else where he was doing the same and got away with it so he can find another company where he can do the same;
- Tom will get defensive. You are exagerating. You are seeing things. Imagining things. He might unwind here and there when he loses productivity but he gets back to the task. He recups his work. Maybe he delivers 70% but maybe that's because he's a bad estimator not a lazy worker. He will probably overestimate things from now on or take less work next sprints.
- Tom will behave in the same way but now he will be more careful not to show it. He will be at his computer, his IDE will be opened but he will stare into space. Or he might be typing code but for a personal app of his. You don't know what he's doing there. People that want to slack off will find ways to do so no matter what you do to prevent it.
- he will start talking behind your back to the other developers. Telling them you have some issue with him. That you are a control freak that insists people are productive 100% of the time. That you can't even look out the window without you pointing out that one should be looking at his monitor instead.
- etc
There might be some resentment, conflict or undesired consequences if you approach Tom about this subject. If you figured out this can't absolutelly be allowed to continue than that's life. Tom is an employee. He gets employee treatement: bad performance reviews, official notices, less salary increases, whatever the company's policy for underperforming staff is.
You say you are not his line manager. Who is? Talk to that person. You are a PM/SM so you can't really evaluate Tom‘s work, you can only observe that he's working less than the others. But maybe he's more productive, maybe his code is better, maybe he works on hard technical tasks that take a toll on his brain power so he needs more breaks. For a developer, time spent banging at the keyboard might not be time spent being productive and doing a proper job. So take it up with his superior (which I hope is another developer, not a manager, or you will have the same problem or worse).
The other alternative is micromanaging Tom. Yes, micromanagement sucks, but for the right people it is the right tool. We all wish employees are proactive, professional, don't need to be told what to do, ask for help when stuck, etc. But people come in all shapes and sizes. Tom isn't the right shape and size so it needs more attention to rough out the edges. This can backfire too and cause Tom to talk behind your back like I mentioned above if he's the only one being micromanaged. You might also start micromanaging other stuff too if you see it brings better results, but that is a very slippery slope for you to be on, which on the long run might cause even more damage to the team and projects than Tom could ever do.
Watever you decide to do, do something. Worst thing you can do is look the other way. Even if your decision is to leave it be for now, but monitor how things are going and take a better informed decision later, it is still better than looking the other way.
Situations like this are never fun, but if you are a PM/SM, they are part of your job description.