We carefully plan out a sprint and decide which stories should be worked on however some developers are working on stuff outside of this planned work.
Scrum is a results-oriented framework, where what is delivered is more important than how it is delivered. Since you mentioned that Sprint Goals aren't being met, you definitely have a process problem.
There are really two fundamental approaches you can take, depending on the skill level and maturity of your team.
- Use your daily stand-up to keep people on track.
- Educate the team and involve line management in tracking the Sprint Backlog.
Use the Daily Stand-Up
The daily stand-up is where team members coordinate with one another about current work, but it can also serve as a reminder about what stories are on-task. This works very well with short feedback loops of 4-16 clock-hours.
A story should be granular enough that it takes one-half to two days to complete. If a story isn't done within that time frame, the team should be hunting for process impediments. In this case, the process impediment may very well be that team members are working on the wrong things, but it could also be that the team has done a poor job of estimating or decomposing tasks for the Sprint Backlog.
As this is a significant problem, I wouldn't wait for the Sprint Retrospective to address this issue. Anytime you have dramatic slippage from the team's commitments, it may be worth involving the whole team (including the Product Owner) and deciding whether the Sprint Goal can be salvaged or whether the PO needs to call for an Early Termination and a return to Sprint Planning.
Involve the Scrum Master or Line Management
While Scrum talks about not allowing outside interference with the team, this has more to do with scope management and self-organization than it does with personnel management. Ideally, a mature team with experience in Scrum would be able to maintain focus on the Sprint Goal, and to use the framework properly to adjust for unplanned work. Of course, not every team is an ideal team.
Assuming that the problem really is "side work" rather than a systemic problem with estimation, overcommitment, or externally-defined tasks, it is not unreasonable for the Scrum Master or line management to periodically follow up with team members to ensure that the work they're doing is relevant to the Sprint Goal.
Ultimately, the Scrum Master's job is to educate the team about the central nature of the Sprint Goal, and to empower them to focus and drive towards its successful completion. Some practical examples might include:
- Decomposing tasks on the Sprint Backlog into less than a day each.
- Asking team members during the stand-up which of the Sprint Backlog tasks they will complete today.
- Checking in with each team member at least once during the day to see if they are on track for completing the task.
- At the end of each day, a task is done or not-done. If it's not done, finding out why is not unreasonable, especially if it's the team that has estimated the task at less than a day's work in the first place.
Accountability, Not Blame
Remember, the goal is not to hold team members accountable for externally-defined timetables. Rather, the goal is to expect team members to be accountable for their own estimates, and to communicate promptly and effectively about anything (including faulty initial estimates) that might jeopardize the Sprint Goal.
Unless the team is composed of incompetent slackers, the objective is to fix the Scrum implementation. Blame doesn't fix processes; motivated people do!