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?

  • 7
    Has anyone asked them why they do it? I can think of about a half dozen potential reasons for working out-of-band, from making up for work he can't achieve during the day, because of the office environment, to simply avoiding dealing with real-world problems. Each of them requires a different response, but most of them are destructive to the team and the Scrum process.
    – pdr
    Commented Mar 1, 2014 at 19:04
  • 5
    Here's the thing. Most of us are highly motivated. And most of us do hobby-programming. I was doing some when I took a break to answer your question. Work programming is often frustrating because it doesn't give us the autonomy that hobby programming gives us. But it does also pay the bills. So when we hobby-program, we often do it on non-work projects. You may be right that the forced distribution is part of the problem. It might also be that he's forcibly taking autonomy, judging by your earlier comments. But ... has anyone asked him?
    – pdr
    Commented Mar 1, 2014 at 19:28
  • 5
    @matt, this is a pretty good example of why "forced distribution" of performance reviews is a disastrously bad idea. It makes people unhappy when their coworkers do more work.
    – user53141
    Commented Mar 1, 2014 at 21:36
  • 13
    Ummmm.... "the programming work is 99% done and just needs code review and testing" -- does anybody else see a serious problem with this statement? If you haven't done any review or testing then your code is, at the most optimistic, 70% done. Probably more like 55%. Commented Mar 2, 2014 at 5:13
  • 3
    I think it's also important to look at where (as in which country) this is happening. I'm in Germany, and there are legal implications with this problem, as to who owns the code if it was not produced in paid time. If we assume the company, then the employee has worked too many hours, and there are laws that regulate minimum rest periods between going to work. If he is younger than the peers, could be he is a trainee. Even more strict rules apply in that case. In Germany I would tell them it's not ok to do this from a legal point of view and the company can get in trouble because of this.
    – simbabque
    Commented Mar 2, 2014 at 9:08

10 Answers 10


Alright, so someone's enthusiastically writing great code that needs to be done, just not in order. With all due emphasis:


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.

  • 9
    I think your font might be a tad too small.
    – Sklivvz
    Commented Mar 1, 2014 at 22:15
  • 14
    Steven: nooooooo... Remember: "Working software is the primary measure of progress." The backlog and ceremonies are just a (good) way to get there. If the tradeoff is between net positive contribution outside of the process and following the process, then the process has to go (or change). There is a huge caveat in 'net positive contribution' though - undesired features, bad quality or too much impact on other teams output do count.
    – ptyx
    Commented Mar 2, 2014 at 18:39
  • 2
    @ptyx you nailed it. +1bacon
    – MetaFight
    Commented Mar 3, 2014 at 3:03
  • 2
    I think OP was saying the coder was productive, not high quality. My team used to have someone producing large quantities of low quality code, had it been peer reviewed its weaknesses would have been highlighted. Management approved at the time, despite warnings, and now have large buggy libraries causing higher workloads. Work as a team guys.
    – daveD
    Commented Mar 6, 2014 at 20:41
  • 2
    @SomeKittens - Fair point. I still think the dev in question is not really working as part of the team/process. A lone wolf can steer the project in a direction it would otherwise not have gone.
    – daveD
    Commented Mar 7, 2014 at 9:24

There are two things I think you should consider here:

  1. Don't hinder someone's creative flow.
    • If a dev wants to do out-of-hours work, then let them.
  2. Don't create work for others.
    • If a dev wants to do out-of-hours work, it sure as hell better not be creating more work for others.

Point 2 is likely what the other developers are worried about.

Like you mentioned, they don't like the fact that the code is written without the entire team's input. This may be because, in terms of design, it ends up being inferior. And code with inferior design has a way of infecting other code around it.

So, what can you do?

Let the ambitious dev code to his heart's content, but make it clear that there is no reason to assume his extracurricular code will be used.

After all, he is part of a team, and so the team should be involved in how all code is developed.

If, however, his work is sound and fits in with the team's agreed upon design then he'll be able to use much of what he's already written (bonus!). If not, it'll force him to think more about his design the next time he decides to get a head start.

This way, nobody gets told NO, and nobody has extra work created for them.


Get him back into the team

You should ask yourself (or better the team, including the overachiever):

Why is this behavior a problem?

Since you label the developer as a overachiever I guess his work is of good quality, so I gonna assume this isn't a problem.

But there seem to other problems:

  • The extra work is not tested properly
  • it is not documented
  • the rest of the team doesn't know it
  • the developer decides on the next thing to implement, not the PO
  • the developer doesn't get any feedback from the various stakeholders to incorporate in his work.

The next Why I would as is:

Why does the developer do it?

  • If at the end of the sprint isn't enough work left, there should be a team decision (including the PO) about what to tackle next. Why does the developer avoid this decision?

Once you have answer to these questions you can start answering your own question:

  • if it isn't a problem, let him do his thing. Although some people treat SCRUM as a religion, it shouldn't be like this.
  • More likely you have two problems in the team: the one(s) caused by the rogue developer and the one(s) triggering the behavior of the rogue developer. Find a way to solve the later and the first one will go away.

Much as I like the idea that adding free work into the mix is a good thing, this isn't free work - not unless that single developer is also the tester, and the QA and the build guy and the designer and everything else. If his work can be put into the next sprint without any impact, then.. go for it. But I think that is never the case. Everyone else, at the very least, has to understand what he's done and what impact it has on them. They have to understand that his changes are in and so not to duplicate his efforts - its hard to tell someone they've worked hard on a task only to find the rogue guy did it last week.

You're working in an agile environment though, and one thing I do know about agile is that it is designed to work for you, not against you. So you need to change the way you work to allow this kind of extra-curricular activity to happen. That means getting everyone's input and agreement, you cannot do this without their buy-in. Its vital. If the team doesn't like it, then the rogue guy stops doing it. End of. It isn't one guy doing what he likes, no matter how good his work might be, its a team effort all the way. The team comes first.

So you need to sit everyone down at the next planning meeting and discuss this, all team members need to decide to allow it, or to change your process to manage this kind of activity better.

Maybe you'll get a solution where everyone works on their favoured projects and brings them to the table (you can imagine the chaos to your delivery that'd cause :) which highlights the problem with it in the first place) or you can mandate area where each dev has automomy to develop whatever solution they like that is the 'contributed' similarly to how many open source projects work, or you can give everyone some free time to experiment (the old 20% time).


Does this developer write tests and clean/solid code or is he/she just pushing out whatever he can get done quickly? I personally wouldn't allow anyone to work outside of the defined hours as it will mess up your estimates and as you pointed out other issues occur.

However, you should never be rigid in your process. Scrum is just a framework so you can always adjust the process to include the extra time (but again its difficult to plan for what someone might do).

You could also ask him to work on things other than the project. Looking at new tech or creating training on things he does differently. Bottom line though is anything done outside your planned schedule will destroy you estimates and I wouldn't let that happen.

  • 1
    Yes, by and large the work is high quality, with unit tests, comments, and usually shares what was done with other developers with a lot of detail (after the fact). We have been estimating as if the work was not done at all, but this leaves the developer with even more time to do out of band work essentially, which causes a sort of feedback loop. We could also do estimates based on remaining dev/QA/doc work that needs to be completed for the story. Some of the out of band work is not part of stories, but pushing new technology into the product as proof of concepts, or major refactoring.
    – Matt
    Commented Mar 1, 2014 at 19:21
  • 1
    this post is rather hard to read (wall of text). Would you mind editing it into a better shape?
    – gnat
    Commented Mar 1, 2014 at 20:03

we faced with same thing as well, basically we committed something like 20 points but at last week or even middle of sprint we ran out of coding task however because of Testing and rest of process we didn't risk to pick another PBI, So what programmers did was to to look into the backlog and start developing future PBIs (silently!) and informing the rest of team in planning that PBI is ready for code review and testing! just like you said.

It actually raised some concern from our POs that it seems we are capable more but we don't fully utilize our team's potential, which was partly true but yes, maybe our programmers could do more but our testers couldn't follow up that speed so there was a risk to fail the sprint. after thinking about this issue we found out that we need to change our view about scrum and the main issue is that people don't want to take that risk is because we Commit PBIs so team didn't feel good to take that risk of picking new PBIs in case that we have free programmer.

Simply we started to Forecast PBIs rather than make commitment. Forecasting basically means we pick 25 points at planning and start of sprint, And when programmer gets free at middle of sprint, because there is no more coding task so he/she picks one of the future PBI and put it in Current Sprint and start working on it, if the PBI could pass all of the process(testing, merging and etc) within same sprint, it is bonus point for team if NOT we don't fail the sprint because of that PBI and just carrying forward the remaining work(testing or meging or etc) to the next sprint and re poker for remaining job. So it can be done in two different sprint in worse case scenario. I know it might sounds like Scrumbut but it actually improved the way that we work. I just can summarize its benefits as below:

  • It defeats the phobia of failing sprint because of taking the risk of taking more PBI
  • It makes the extra work of your programmers and team visible
  • It increases your team velocity

However maybe for a team with less experience, maybe it reduce the push that commitment gives to the team to finish the PBIs


Some of the other answers have suggested that the "overachieving" developer is "rogue" or "violating the principles of Scrum". This is incorrect and this developer should be encouraged (although you should not ask people to work on anything specific in this extra time, but you could make suggestions and help foster ideas).

There is nothing in Scrum to prescribe how people work and anything extra he did would naturally be incorporated into the velocity of the team.

His work should be brought in to the product backlog and estimated in the next planning meeting. If you can't predict what the remaining effort is straight away you should time box some time of the sprint to figure it out (that is, a Spike).

Interesting you describe the developer as "overachieving", I assume this means he is adding a lot more value than the other team members.

The difficulties doing extra work creates implies there is something sub-optimal (or maybe even dysfunctional) in your team.

If this is the case, you should ask yourself why is he achieving so much more, with presumably only a little bit of extra effort?

Is it possible for you enable the rest of the team to achieve more?

I've seen the situation where teams have been micro-managed, potentially over prescriptive user stories, definition of done, which ends up being stifling to developers. Is this developer doing the work that he wants to? I'm assuming he is making good decisions. Would working this way in the working week help the rest of the team too?


Have them also be a teacher

It is great that you have a star developer with the best and most advanced skills in the group. I would praise and compliment this. Often such folks are the 'glue' that hold organizations together.

I would view the challenge as 'how to get less experienced developers closer to the productivity of the most advanced developer'.

One great way to do this is to focus on getting the star developer to spend more time teaching, training and guiding the less experienced and slower team members. I would first discuss this in a 1-to-1 with the star developer so they know what you are doing and why. Other wise it may be viewed with suspicion as a hidden agenda / poor managment

When you do standups, once or twice a day, if this person runs out of work and others are still doing tasks, look to pair-programming so that she can pair with the junior members and impart her great knowledge and experience. Make sure to ask the question "does anyone need help? Is anyone looking for a pair?"

You could also find some 'side' work for the best developer for when they are out of work, such as enhancing the toolset being used by all, running a technical book club discussion group or being involved in other organizational projects.


I'm going to answer a different question. I think how to deal with this situation in Scrum is really not important. Scrum is more like a guideline anyway. If you want this to happen find a simple way to adapt your process like simply assuming the work is already done.

The real question is whether you want this dev to do what he is doing. I think several aspects play a key role in the answer to that question:

  1. Is the programmer doing good work.
  2. Is everybody okay with him doing his work on his own (be it good or bad). He is dodging the design process, after all!
  3. Are the extra hours paid or not.

All of these influence whether it makes sense for your product that he is doing what he is doing. Again, incorporating your decision in the design process is not really an issue. Just be flexible.


This violates a tenant of Scrum because the team is not deciding the work in the sprint. This is a scrum team. The team needs to discipline this programmer if discipline is to be handed out.

Another issue this creates is that it screws with the team's velocity. Out of band work does not count towards velocity and burn down. So, this out of band work gets done, the team is averaging 50 points in velocity, but more than 50 points gets done. The product owner will see this and demand higher velocity in the next sprint. Velocity that might not be possible.

The team (not the PO or the ScrumMaster) needs to address this with the rogue programmer.

  • 3
    You use the word rogue programmer to put a bad label on someone that is actually going beyond the call of duty and based on other comments is doing a good job.
    – boatcoder
    Commented Mar 6, 2014 at 21:52
  • 2
    Wait, I thought the mantra of agile development was "people, not process"? Commented Aug 28, 2014 at 23:07
  • Good luck building a real, successful startup product with an attitude like this.
    – Kelseydh
    Commented Apr 26, 2017 at 7:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.