You mention sprints and retrospectives, so I assume you're following some variety of Agile. The heart of Agile is the concept of continuous improvement, and a team empowered to enact it. If you're bored, then congratulations: you've found something that can be improved. Here's some ideas:
A retrospective that takes 90-120min is way too long. Next time you have one, take a notebook, listen in carefully, and note down any time you feel like things are taking too long.
- Are people repeating each other's points? Perhaps you could all put your suggestions on notecards or post-its, so that they can be rapidly grouped and discussed as one, rather than rehashing the same things.
- Do people miss things, and have to have it repeated? Maybe it's as simple as a "no phones/laptops/distractions" policy so that people stay aware of what's already been said.
- Does the meeting go off on tangents? Perhaps the meeting needs a chair who will step in and keep things on track - or the person who is already supposed to be doing that is not very good at it. Maybe you could start (politely) pointing out when things go off-topic, rather than starting to look at your phone or whatever.
- Does the discussion go into unecessary detail, or focus on a niche that only involves a few of the people present? Maybe you could ask if there's anything the other people could contribute, and if not, suggest that those involved discuss it outside the meeting and report back at the next one if necessary.
- Are there people in the meeting who aren't needed? Everyone present should be part of the discussion, which means that they provide information, take part in discussions, and go away knowing something they didn't before. If they're only there to provide info, then they could present and then leave, or even just send a report for the attendees to look at. If they're only there so they're aware of the outcomes, then they can skip the meeting while someone present takes notes to send to them afterwards. Since you're already taking notes, you could volunteer for this role - it's often a great way to learn about how things work at a company, which is useful for a junior.
Fill Your Time
If you're completing all your tasks for the sprint and still spending a couple of hours per day on your phone, then clearly you don't have enough work to do. Meanwhile, you mentioned that other developers frequently don't complete their assignments, which implies an issue in your process.
- If the team as a whole is routinely not finishing the work they committed to for the sprint, are you taking on too much? Next time you're planning the sprint, you could point out how much unfinished work you usually have and ask whether you should scale down your ambitions for the next sprint so that it's actually achievable.
- When you run out of work, could you assist the other developers in finishing their tasks? Maybe the reason you keep taking on work and not finishing it is because there's the right amount of work, but it's unevenly distributed so that your tasks are smaller and easier to finish, while others are working on larger things that take longer. If you're a junior, then the others may be working on things that are more complex and more likely to keep you interested, and you'd be helping the team to succeed. Less unfinished work also means less things to discuss in retrospectives, which makes those meetings shorter.
- Could you assist your QA or testers by running through the UX scenarios or test scripts? Less time spent waiting for tests to finish means work is finished faster, and seeing those tests in detail is often a good way to learn more about your software's use cases and to spot possibilities for improvement that you would otherwise have missed.
Improve the Process
If you can't help directly, is there anything you could do to speed the process? It might be that the other developers are spending a lot of time waiting for things, or that there are things they're doing that could be faster. If you've got time to be on your phone, then you've got time to tackle some of these.
- Can you automate anything repetitive? Software development contains many tasks that are done the same every time - builds, tests, deployments, etc - and these can usually be automated. This means that developers are now free to focus on more varied and interesting work.
- Is there anything difficult or error-prone you could automate? An automated process means less chance for human error, which means less time wasted on mistakes and less to talk about in retrospectives.
Keep Things Tidy
There are usually some side jobs available with software.
- You could check the backlog for low-priority bugs that you can fix easily.
- There might be some simple changes that have been requested that weren't made a part of this sprint, like changing wording in the UI, styling changes, or small tweaks, that you could fit in to make use of any spare time.
- There may be documentation that needs writing or updating.
If you've been through all the above, you may have found some things that could be done, but you can't do them yourself. Perhaps this is because you don't have the expertise, or because you're not familiar with the code involved.
- Is there a training course you could work through to gain a new skill?
- Could you spend some time reading through some code you haven't worked on before, in preparation for working in that area?
- Is there an area of the codebase known for being hard to work with? Perhaps you could look at it and do a little code review to see if you have any ideas for improvements to suggest.
- Could you shadow a more senior developer, or even try a little pair programming, to improve your skills and experience? Maybe you can't help with their task, but by observing, you might learn what you need to be able to help out with the next one.
If all else fails
As you go through all these points, you may find things that you can see, and want to do, but are prevented by management, company policy, the apathy of your colleagues, etc. This happens sometimes, but if it's quite common and you find that you're stuck in an unpleasant working situation because they won't let you fix it (rather than other, more reasonable causes) then it may be that you just landed in a bad company and you'd be better off seeking out somewhere better.
If you've been through the whole list and decided that actually, all these things are fine, your processes are perfect, the code is excellent, and there really is nothing more that can be improved... well, then please tell us where you work, and if they're hiring.