We have a "typical" SCRUM team and we commit to work for a sprint, and also maintain a backlog. Recently we have run into a problem of trying to integrate/handle the work of an overachieving developer doing out of band work (choosing to work outside of the normal working hours/sprint).

To give an example, if the team takes in 50 points of work, let's say that they will complete all that work within the SCRUM framework by the end of the sprint and they and the company is happy. One of the team members decides to work on their own, on a backlog item, on their own free time. They do not check in this work, but instead save it (we use TFS and it is in a shelveset).

How to handle this? A few of the problems ..


During the next sprint this team members says the programming work is 99% done and just needs code review and testing. How do you deal with this in the SCRUM and agile methodology?
Other developers complain about not being involved in design decisions related to these stories, since the work was done out of band.
Our product owner is tempted to pull in this "free" work and the overachieving members is likely doing this on purpose in order to get more features into the product that the team otherwise would not be able to accomplish in the sprint(s). There is a view that this is breaking the "process". Obviously QA, UI and documentation work still need to be done on this work.


I see a lot of discussion about not forcing a SCRUM team to work overtime, but what about a member of the team working above and beyond the expectations put forth during planning and execution of sprints? I would hesitate to reign this person in and say you cannot work extra (cautioning on burn out of course), but at the same time it seems to be causing some issues with certain members of the team (but not all).

How to integrate work done by an overachieving member into the SCRUM and agile process for software development?

Alright, so someone's enthusiastically writing great code that needs to be done, just not in order.  With all due emphasis:
LET THEM
It's causing some complications in your scrum sprints.  Does it really matter in the grand scheme of things?  If he's accomplishing what he's supposed to, then let him go on and build great things for you.
I know several amazing programmers who have left companies because they did not let the programmers outside of the constraints of an artificial system like Scrum (I myself left my last job after being treated like nothing more than glorified QA).  If there are complaints from other developers about input (perfectly valid complaints, I may add), it may be best to introduce a "20% time" program to let him (and others) do what they do best with minimal interference.
Instead of future stories (that may require input from others), let the developer experiment with new tech or features.  You may find a great new opportunity that never would have been explored otherwise.  I'm sure this developer has a few things they'd like to try out if you just let them.
