A
TL;DR
I told the developer to stop working on anything not prioritized by the Product Owner regardless whether own time or not.
From a framework point of view, this is likely to be the correct approach. It's certainly what I would recommend as an organizational statement of policy. It reinforces Scrum processes and practices (e.g. time-boxing), and reduces risks to the organization, the team, and the developer himself.
However, from a psychological point of view, the correct team-management answer is less clear. A person's personality and drives, as well as his individual requirements for remaining tightly engaged in a project, need to be balanced in terms of the overall benefits to both him and the project as a whole.
What follows is an examination of some of the benefits and risks associated with allowing off-the-clock work. It is certainly not exhaustive, but should provide a solid starting point for your own risk/reward analysis. Your mileage will definitely vary.
Benefits
There are a few potential benefits to letting the developer work on something he's passionate about in his own free time. These may include:
Supporting his passions.
Many knowledge workers value personal achievement, pride in their work, and the approbation of their peers at least as much as they value a paycheck. Supporting these values can be good for individual and team morale.
Personal growth.
Encouraging developers to grow as programmers by expanding their knowledge of programming techniques solving problems they find interesting may lead to improved code quality and new insights for the team. Doing this outside working hours costs the company nothing, financially.
Individual investment.
Someone who feels passionately enough about a service or product to work on it on his own time is likely to be more engaged than someone who just wants to show up every day and collect a paycheck.
Product quality.
People who are passionate about their work may be inspired during through their off-hours activities, whether or not those activities are directly related to the project. The project can certainly benefit from such inspiration, and (barring any risks as detailed below) such contributions may improve the overall value or quality of the team's product.
In short, caring about one's work or about a project that consumes close to 40% of one's waking life is generally a Good Thing. On its face, there would seem to be few reasons to discourage this, but the potential upsides should be carefully balanced against the potential downsides for all involved.
Risks to the Team
The risk to the team is that it may encourage the organization to think about non-billable hours as available for their estimates. Scrum is specifically about setting a sustainable pace within time-boxed iterations, so work that occurs outside the time-box skews the metrics and sets unsustainable expectations for the team.
In addition, it risks confusion about some core agile principles such as:
Time-boxing. Something is either done or not-done within a time-box, and you don't want to set the precedent that time-boxes can be disregarded.
YAGNI. If the feature isn't part of the current Sprint, and isn't important enough to the project to be a priority on the Product Backlog, then it isn't important enough to expend resources on. Even if it's just the developer's personal resources, working on YAGNI items sets a bad precedent for the team. It may also reduce respect for the Product Owner's essential role in setting project priorities.
Risks to the Organization
While unlikely to be a significant legal problem with the one-sided, work-for-hire contracts most IT workers sign these days, it's still a bad precedent to accept unpaid, private work into a commercial code base that isn't under an open-source license. You might want to consult your legal department about this, but it just seems like a Bad Idea to me.
Risks to the Developer
The developer himself runs a few risks here. In particular:
He risks developing bad habits related to time-boxing and sustainable cadence.
He risks a poor work/life balance that makes sustainable pacing at work more difficult.
He risks losing sight of the collective ownership of the code by thinking of portions of the code as "his."
He risks identifying with the code quality of his contributions, rather than with the ability of the team to deliver value within a time-box.