Scrum being a project management methodology, how would you 'sell' it to the developers in a team that is reasonably happy with its current situation?

It seems easy to me to explain to our Product Manager how Scrum will allow him to get regular releases, to amend requirements, and get the team to focus on the high-priority stories first. I found it easy to explain what TDD or Continuous Integration bring in a developer's day-to-day life.

But how can developers be convinced to embrace Scrum? How would Scrum make their life easier?

closed as too broad by gnat, durron597, Ixrec, user22815, user53019 Sep 23 '15 at 21:24

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.


Scrum will provide much more visibility on what is going on. Bad management, last minute changes, pressures, and all kind of stuff a developer usually face.

However, it will also bring a lot of visibility on procrastinators, bad faith developers, insane individualists, ... in other words, bad developers.

Scrum is a double edged sword

Scrum will bring you with opportunities to solve those problems. That's why it's so powerful.

  • 2
    What is a "bad faith developer"? – smp7d Apr 11 '12 at 18:15
  • 3
    Developers than spend the work they are paid for, for something different, such as working on their private projects or surfing internet aggressively. – user2567 Apr 11 '12 at 18:19

Breaking the big goal ("get the software done") into smaller pieces - stories - and deciding which of them to do at the current sprint improves productivity and reduces stress. When you know specifically what you're supposed to be doing now, there's little to stress about, and you can focus on doing the little piece instead of feeling overwhelmed by the large whole.

  • While true, Scrum isn't a pre-requisite for user stories and prioritization. So how does Scrum make life easier? – Steven Evers Oct 20 '10 at 17:33
  • 1
    While not a pre-requisite, Scrum is one way to do it. So to be exact, the question should be something like how does Scrum make life easier compared to X? – Joonas Pulakka Oct 21 '10 at 6:02
  • ... compared to waterfall. We already have automated builds and continuous integration. I try to introduce TDD. But we have up-front detailed requirements and estimates, long development cycles (several months), weekly status meetings... – Xavier Nodet Oct 21 '10 at 7:17
  • @SnOrfus as no stories can be added during sprint so Scrum makes life easier by reducing stress. Developer knows that this is what he will be doing and no one will change the priority during the sprint. – Asim Ghaffar Jul 23 '11 at 7:38

Stack Ranks / Backlog keeps milestone ends from being death-marches

As a developer, the 'destructive pattern' I see most in software development is when some 'external controller' (e.g. project management, executive management) gets very excited over the fact that 'favorite feature' isn't going to make it on 'calendar date' and orders a death-march.

Scrum, because it ranks 'important features' high in a backlog list helps developers manage this tension proactively in two ways. First, you can rank 'favorite feature' high in the backlog so that s/he is most likely to be happy. Second, it gives a very visual and concrete answer to "since we moved 'blinking widgets' to rank 1, it's very likely that we're not going to get to 'bouncing bunnies' in this sprint since it is now rank 7. Are you comfortable with this trade-off?"

I've also found that with short sprints, 'external controllers' are less upset about postponing work. If 'blinking widgets' doesn't make it into 'milestone 1' and 'milestone 2' doesn't end until 9 months from now, the sponsor of 'blinking widgets' gets very upset. But if 'blinking widgets' is stack ranked 7 instead of 1 because there really are 6 more important things that have to get done first, this means that we'll probably get to it in sprint + 1 or at worst sprint + 2 which means it will show up 12 or 18 weeks from now (using 6 week sprints). In my experience, waiting 3 months is 'acceptable' to the impatient -- besides, back in the 'waterfall' model of 3+ month milestones, waiting until the next two sprints end is the same calendar time as waiting until the current milestone ends.

Finally, if we're reaching the end of the sprint and things took longer than expected, it's very nice to be able to push backlog items 5-6-7 to the next sprint and make sure we've completed 1-2-3-4 with high quality and without 70 hr weeks. After all, we'll be sure to get to 5-6-7 next sprint. Again, given the shorter timeframes involved in the postpone, 'external controllers' are generally more comfortable with this and don't insist that we slip the milestone two weeks and order dinners each night 'to just push through it'.


People in a Scrum team get to decide many things by themselves: what will be done during the next sprint, how do we break this story in tasks, who works on what, etc. This empowers them, and is almost the exact contrary to micro-management.

  • I think that is a bit unintentionally overselling it! "What will be done during the next sprint" has to be decided with reference to the product backlog and the priority of the items on it. Of course, "how much will be done during the next sprint" is definitely decided by the team. – Robin Green Jan 5 '14 at 13:15

The fact that requirements will change is taken into account right from start. Developers don't need to create detailed specs with precise estimates and then spend weeks developing a feature only to realize that the customer changes his mind as soon as he sees the result...


For me, you get to self assign tasks from the backlog is the biggest selling point from a developer point of view. Also, the intimacy with the customer / product owner helps understand the larger scheme of things.


A couple of things:

  • Building on Xavier's point about requirements changing right from the start - a less political atmosphere develops when everyone accepts from the start that some things will not be as the client expects. Quick delivery and review will mean that the cost of mis-communications is low, and instead of playing the blame game, the developers can just change things so that they do work as the client expects.

  • Story points! What developer doesn't like getting points for doing stuff!!?! Seriously, it's better than getting badges in SC2 or Stack Overflow.


There are several things that I as a developer like about scrum.

The developers tend to be given more information upfront. The product owner needs to explain all the work that is going to be done during the next sprint in sufficient detail to allow for good estimates.

Just in time estimating means that that estimates are reasonably accurate. Everyone usually has a reasonably good idea of what will be finished in a sprint. This gives programmers and project managers the tools to push back against unreasonable demands.

It is nice to step back every three to four weeks and take a breath and at least have a change of pace.

Self organizing teams, seem to give a bit more variety in the work.

In theory at least, during the sprint there are fewer interruptions and 'emergencies'.

The daily stand up meeting forces programmers to say several words every day.

It is easier to see the progress being made as stories are explicitly finished and reviewed at the end of each sprint.

The burn down charts are a pretty effective light weight means of tracking progress.


Advantage for developer is early feedback (from client, tester, Product owner etc).

Also as a developer, i am always interested in doing things step-by-step without distraction. Scrum provides this.

PS: scrum is not a methodology it is a framework.

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