You need to get the entire team to help each other to improve. Not only will this make work more interesting, it will also mean that inexperienced coworkers get frequent feedback from several sources. Feedback from one person is much easier to dismiss than feedback from many.
This is a management issue and as such should be raised with management. It's a standard issue with standard answers. If management is not aware of that, your real problem is not that you need to educate the coworker, but that you need to educate the managers. That one is harder.
You mention "story" and "sprints" so I assume that means you work in an Agile environment. You also mention that stories take multiple sprints (as in "more than 2"), so I have to assume the company doesn't have an efficient Agile environment yet, and is open to improvement.
The standard approaches to solve your problem in the context of an Agile framework, as I know them, are as follows:
Frequent peer reviews
- Enforce frequent check-ins. Code that compiles and runs should be checked-in several times per day, and be built by the build system and run against all automated tests. Yes, the build will break a few times each week, but it should be fixed within 5 minutes each time.
- Enforce peer reviews on all check-ins.
Once this is agreed on by a management committee such as the Scrum of Scrum (or the equivalent in your company) this can be enforced with a script that requires check-in descriptions to state the name of the reviewer. Such a script can be written in less than 30 minutes.
Collaborate on stories
- During sprint planning break down stories into tasks, as a team. Aim to have tasks that shouldn't take longer than half a day. If you aim for all of the tasks to take more or less the same amount of time you can keep the sprint planning meeting quite short because there's no need to put estimates on the tasks.
- During a sprint, have as many people as possible work on one story at the same time. Finish stories as a team, one story after the other. This can involve agreeing on pair programming as a team.
Raise and fix roadblocks
Use the daily stand up meeting. It is visible when someone gets stuck, often before they themselves realize it. If someone picks the same task 2 days in a row, raise a red flag. The tasks were supposed to take about half a day. There is a reason which causes the task to take more time, and it's not procrastination. If the task is more complex than anticipated, split the task into 2 tasks. If the task requires more expertise the one working on the task should pair up with someone who has the expertise. If the task is blocked put the task back on the board.
Enforce Pair programming
This is one of the standard solutions, but I don't like that one, at least not as a permanent solution. People should pair program because they want to, not because they are told to. Therefore I'll add some more opinion here: If pair programming is enforced then it should be done with the purpose to train the developers on the concept. To do that, it should come with a time limit, 1 or 2 sprints. For example one could say "Many of our developers don't have much experience with pair programming, and we want to change that. To do so, pair programming will be mandated for all work for 2 sprints, starting with the sprint after next. After that it will be your choice if you want to pair program."
