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.

This is undermining the whole process.

What techniques can we use to encourage/enforce developers to stick to the planned stories?


  • Having talked to the developers we know they are working on the stories because they find them interesting or consider them important.
  • We have tried no techniques so far except asking/telling the developers not to.
  • Developers are working on both planned and 'personal' stories in parallel.
  • The planned stories are sometimes completed but often not.
  • The non-planned stories being worked on are legitimate pieces of work, just ones not prioritised into the current sprint.
  • The extra tasks being worked on are not refactoring. We consider refactoring to be part of a story, not a separate story in itself. http://xprogramming.com/articles/refactoring-not-on-the-backlog/
  • It is only a small number of developers in the team that are doing this, and they are a mixture of experienced and junior developers.
  • We have contractors on the team however it is the permanent staff that are going off-piste.
  • The team has been working together for a few years although there are some new members of the team.
  • We recently moved from Kanban to Scrum. We are in our 2nd Sprint. The developers in question have a history of going off-piste. I guess the original question might have been better worded: "In the Scrum methodology, what techniques can we use...?"
  • The issue has been raised in the retrospective and the problem persists
  • This seems to be a good basis for a question. What have you tried so far, and what were the results? Do you know why they are working on stories that are not in the plan for the current sprint?
    – Iain9688
    Commented Aug 6, 2014 at 16:52
  • @Iain9688 I've updated the question. Thanks.
    – rdjs
    Commented Aug 6, 2014 at 17:01
  • What is your role in the team? Scrum Master or Product Owner? Commented Aug 6, 2014 at 17:25
  • @ashok I deliberately left roles out of the question as I wasn't sure if that was relevant. In this particular situation however I am the Scrum master.
    – rdjs
    Commented Aug 6, 2014 at 17:52
  • 1
    @rdjs I mentioned in my answer that the problem stems from a weak Scrum Master. Now you have detailed yourself as the SM I hope I didn't offend you. Given the move from Kanban to Scrum I would edit my word weak to mean inexperienced. The fact that you are at PM.SE seeking a solution is evidence you are committed to rectifying the situation. I have worked in Agile teams where staff dismissals were necessary to ensure team unity and deliver value to the Product Owner and shareholders. Remember, the developers are playing with Other People's Money. You have a fiduciary responsibility. Commented Aug 8, 2014 at 17:38

6 Answers 6



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.

  1. Use your daily stand-up to keep people on track.
  2. 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:

  1. Decomposing tasks on the Sprint Backlog into less than a day each.
  2. Asking team members during the stand-up which of the Sprint Backlog tasks they will complete today.
  3. Checking in with each team member at least once during the day to see if they are on track for completing the task.
  4. 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!

  • I can't agree with your last couple paragraphs. If you were told to do one thing, and you did another, and now the project is behind schedule when it wouldn't have been if you would have done what you're told, you're to blame. Regardless if it was the right thing to do in the long run, you do what you're told until you convince management otherwise.
    – corsiKa
    Commented Aug 7, 2014 at 2:35
  • 1
    @corsiKa Sorry, no. Stories are never assigned; they are accepted by the team into a Sprint, based on the team's estimation of its current capacity. If you have questions about this aspect of the framework, please open a new question or move this to chat.
    – Todd A. Jacobs
    Commented Aug 7, 2014 at 2:53
  • 2
    Assigned, accepted, pick your word, it's just semantics. The point is developers sign off to the payload of a sprint. If they don't intend to work on that payload for whatever reason and yet agree to it anyway, they're bad employees.
    – corsiKa
    Commented Aug 7, 2014 at 3:01
  • 1
    It's not clear from the question what exactly the developers were working on. Perhaps the managers just didn't ask "Why" enough times to actually get an answer that they understood. For example, if they said they're refactoring the DB wrapper, and they're doing that because it is needed as part of adding in something for the story, and the manager doesn't understand, then that can look like the dev is goofing off. I suggest clarifying the question with exactly what the dev was doing.
    – jmort253
    Commented Aug 7, 2014 at 7:21
  • 1
    @jmort253 We don't consider refactoring to be a separate story. The stories being worked on are legitimate pieces of work, just ones not prioritised into the current sprint. I'll update the question.
    – rdjs
    Commented Aug 7, 2014 at 7:43

I think I'll be contrarian here, perhaps because I'm a developer rather than a product manager. To me the developers consistently working outside of the the "agreed upon" task list suggests that there really is not buy-in to the task list, but rather the developers are acquiescing to it for political reasons while not actually agreeing with it. A well-functioning Development team feels great ownership in their work and the product, and will defend the product if they feel that it is being threatened. (Although they may be right or wrong in their perception).

So to me the real question is why, as a team, you can't agree on the direction to take. You have stated that a major reason for the unauthorized work is that Development believes it is important. There really seems to be a fundamental disagreement regarding what needs to be done. That needs to be resolved politically with Development. Rather than asking "how do we make them do what we want?", you should be asking "how do we all get on the same page?" It would also be interesting to know what the rest of the development team feels about what's going on.

I'll also note that, as inconvenient as this may be, programmers really are artists, and they're kind of going to do what they want to do regardless of what anyone else thinks. Or, alternately, they will be dramatically more productive when doing things that interest them or that they feel are important. Effective management will aim individual programmers at tasks that they are attracted to. I know that the Agile model frowns upon this, and actively takes steps to try to negate it. Nevertheless, if you want a productive team, I wouldn't ignore it. If the "disobedient" developers are high performers, then I would suggest giving them leeway. (And that would also further suggest taking their concerns seriously). If they are low performers, then perhaps the team would be better off without them.

  • The way Scrum works is the product owner decides what the direction of the product will be and then the team picks what parts of that strategy they work on. It's not a dictatorship, but it's also not supposed to be complete anarchy with developers just doing whatever they please. Also, you should review your answer and ensure you're answering the question, "How can we stop developers from working on stories that aren't planned?". Hope this helps.
    – jmort253
    Commented Aug 7, 2014 at 8:13
  • 2
    The point of my comment was that if there is an ongoing systemic problem with Development not following the plan, then perhaps the issue is not really of how to enforce discipline, but rather of how to choose a plan that Development is comfortable with. This is very much speaking to the question. You stop them by planning stories that they agree are useful. To me this sounds like there's a disconnect between the PO and Development that needs to be resolved. Address the problem rather than just try to suppress the symptoms.
    – David
    Commented Aug 7, 2014 at 17:56
  • Hey David, thanks for clarifying and weighing in from a dev perspective. I suggest editing that summary into the post body so it's more visible.
    – jmort253
    Commented Aug 7, 2014 at 21:37
  • +1 for focusing on the (possible) broader problem instead of just a symptom. Btw my understanding of Agile is that it is precisely not trying to suppress developers' individual drive and motivation (artistic dreams if you will), rather aiming to work with it and use it as a positive force. That the ideal agile team is self-organizing means that there is noone to dictate them what to do: they will commit to it by their own will. The PO can't force them to be enthusiastic about the product, only share with them the product vision in a compelling enough way to stoke their enthusiasm. Commented Aug 8, 2014 at 15:20
  • I gave an up vote to David and TL;DR. Both are looking at two different angles to the same issue. TL;DR addressed how to fix the current problem. David is looking at what might be the underlying cause to prevent it from happening in the first place. While Spring goals may not be being met, I wonder if release goals are? While we would like every sprint to be "releasable" reality usually means it takes a few sprints together to meet an external releasable product. Is the customer being satisfied or are we not shipping at all? Commented Aug 12, 2014 at 19:54

Address the legitimate concerns of the developers first

Product Owners tend to be razor (!) focused on delivering features to the end-users. Technical debt tends to be put in the back burner. Hard-to-read code, duplication, tangled dependencies are all examples of technical debt that you have to pay down. Otherwise the developers end up paying interest in every sprint.

For example, in one of my earlier projects, we used to make a copy of the schema for new data loaded for each year. We proposed converting that to a single schema using the year as a key so that multi-year data can stored in the same schema. This involved some amount of development and a lot of testing to make sure the existing production sites don't break. The Product Owner was just not convinced that we should invest the limited bandwidth to fix this. The tech team finally convinced the PO by providing estimates of how much less effort it would take in subsequent years to do this repetitive annual work.

Provide a process to discuss what work the developers consider important. Possibly this can be done during story time (backlog grooming). Make room in the sprint for work that is accepted as important. After you provide such a legitimate avenue to address the developers' concerns, then you can be strict about any deviations.

  • 1
    The extra work being done outside of the planned sprint is not technical debt. We don't believe technical debt is a separate & valid user story.
    – rdjs
    Commented Aug 7, 2014 at 8:51

Bear in mind that any approach needs to be aligned with the personality of your organization. For example, addressing compensation may mean giving out net new bonuses as an incentive at one company, while at another it could mean taking money or perks away.

  1. If you want to appeal to the mercenary in them you could try tying compensation to on-time, on-scope completion of sprints. This should get most of your team focused on completing the planned sprint before doing the "fun" stuff.
  2. Along these lines you could tap those that are regularly delivering according to sprint scope/schedule for recognition.
  3. As a last resort, if sprint scope/schedule are regularly being impacted and the carrot approach isn't working you may need to consider the stick of some form of disciplinary action. For example, you could make adherence to sprint scope/schedule a category on their annual performance reviews.

In addition to the excellent answer by CodeGnome I would also investigate the following items:

  • Are the Developers finishing the Sprint Backlog and have the capacity to work those stories they now deem interesting?
    • If the answer is [YES] then the Scrum Master should reevaluate the Planning Poker to find out why the Sprints are so conservative in their planning.
    • If the answer is [NO] then the Scrum Master has a duty to ensure the Product Owners priority is being communicated and adhered to.
  • Has the issue of personal priority of the backlog been raised at a retrospective?
    • If the answer is [YES] then the Scrum Master must take action if the issue is undermining the team.

This issue seems like it stems from a weak Scrum Master.

To add some context can you elaborate on the following:

  • Are the Developers contractors?
  • Have the Team been working together long?
  • How many Sprint Retrospectives have you had?
  • Does the Team have a history of going off-piste?
  • Is it one sub-set of developers or the whole team?
  • 1
    There are lots of questions here, I'll try to address some of them by updating the question.
    – rdjs
    Commented Aug 7, 2014 at 7:55

Are they strictly working on only unplanned stories, are they working both in parallel or are they finishing the plan and taking on additional load? so first of all it is essential to know the reasons behind. Are they personal reasons? Preferability tk work on some aspects and not others?or are the stories mature enough to be developped? What you can do is stick to their overall time estimate, enforce them to breakdown their tasks and call for an immediate meeting after the time us up.

  • Working on both in parallel. The planned stories are sometimes completed but often not.
    – rdjs
    Commented Aug 6, 2014 at 17:19
  • @rdjs - Perhaps you can edit your question to clarify and then user5529 can edit so this is more of an answer. If you edit, the post gets bumped so others will see and can update their answers.
    – jmort253
    Commented Aug 7, 2014 at 6:59

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.