How can we stop developers from working on stories that are not planned into the current sprint?

Question

ORIGINAL QUESTION

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?

UPDATES:

• 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

Answer 1

TL;DR

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!

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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?

Answer 6

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.