Reprimand is very strong word. And it's not a question of can you do it. Of course you can reprimand anyone you want. But should you do it? I find that when management/leadership takes this type of approach, it generally demoralizes the team and doesn't really improve anything. So you tell me, I can't be on P.SE during work hours. How would that translate into me giving you higher output?
As others have mentioned, low output and people browsing the internet is an effect. Your question is how do you fix this symptom but you need to look deeper for the root cause.
And before you look too deep (and the reason why I want to add my 2 cents here) is you (and possibly some of your management) should familiarize yourself with the core ideas behind Agile and motivations to have those ideas in the first place.
In essence, Agile advocates a decentralized form of control, where the management sets general direction but leaves everything else up to the team. Decisions such as how we are going to deliver, how long its going to take, what technology to use, who will work on what. The team should decide that on their own. The reason for that is because people doing the work, really have the most knowledge about how to do that work and when it comes to schedules, if my boss tells me that I have 5 days to finish a task, I go back to my desk and continue working as usual. If it takes 10 days, it must be poor planning on my boss' part. If it takes 4 days, I'll spend the other day doing who knows what. Whereas when your developers make the decisions, and developer is the one who says, it shouldn't take me more than 5 days, that developer has a stronger personal pressure to deliver on his word but it only works if those 5 days aren't shoved down his throat from up top.
As you keep doing your sprints, part of your process should be to continuously look for improvements, which is what retrospectives are about. And again, the whole thing is completely developer focused. "Guys, let's discuss what slowed you down and what frustrated you." Identify the biggest frustrations and eliminate those first and repeat. People will feel more energized and motivated to deliver if they see that the company structure is designed to help them and make their lives easier.
If you do it right, your entire team should get into the mindset (it will take some time but not as long as you'd think, I've seen it done in 3 months) of we are in this together. We control our schedule. We want to build a great product. The key is "we". When you get to that point, a) if someone isn't carrying his own weight, his own teammates will call him out and ask, Bob "we" are waiting for you to finish this, what's up?? and b) people will feel more strongly about delivering because their own teammates, not management, are depending on them. So when you get to that point, there will be absolutely no need to reprimand anyone.
This answer is based partially on Agile, partially on management theories they teach in MBA school (yes I went back to school to get masters degree in the dark side), and partially on my own experience in my previous company. I had a great boss who let me try all kinds of things with our team. We implemented a lot of the ideas that "true" agile advocates, and although we haven't fully gotten there (didn't have regular retrospectives and unit tests were significantly lacking) but in terms of attitudes, motivations and general ethic, our team really did turn around 180 degrees in 3 months. And while we worked hard, and often logged in at night or at other random times just to complete stuff here and there, a) no one ever asked or forced us to work extra hours and b) we were probably the happiest development team in the entire organization because a lot of corporate BS stopped at our manager.