1. Write it as SCRUM – It’s not an acronym.
2. Create user stories – It’s a XP thing and a very good way of documenting expected outcomes not requirements; there are other ways too.
3. Do a “Stand Up” – Daily Scrum is important, standing up isn’t. Next time feel free to relax. Just finish it within the 15mins timebox.
4. Measure Velocity – Especially with a modified Fibonacci sequence like in Planning poker. Estimation is important, estimate isn’t.
5. Create a Burndown chart – It used to be a Scrum artifact and has been removed because it doesn’t provide any new information that we doesn’t already know.
6. Focus on Iteration – Increment is a Scrum artifact not Iteration. If there is no improvement based on empirical evidence in the process or product, it’s not Scrum. This is why there’s a steady cadence of a feedback cycle aka Sprint Review.
7. Implement any practices like TDD, Pair programming or continuous integration – These are, again, part of XP not Scrum. Whether you do it or not, it doesn’t matter as long as you are providing a working software with valuable outcomes in a good quality when the sprint ends.
8. Miss a Retrospective – That’s when we inspect and plan to adapt. In fact it is the most important event of all. You cannot cut down a tree with a blunt saw.
9. Hire a mixed role as a Product Owner/Scrum Master or Scrum Master/Developer or weirder combinations. You might think you are saving money, you are not. You are risking to loose more than double of the amount you think is being saved.
10. Not read the Scrum guide or share it with everyone involved. Any description or roles and responsibilities not referring to Scrum guide is an attempt to implement zombie scrum.
11. Not set a Sprint goal or not taking seriously when set.
12. Have a line manager who is against the notion of agility and Scrum by default.
13. Swap work items after sprint starts, resulting in a change of scope. Again it’s a XP thing, not Scrum. Doesn’t make it bad, but we should know why we are doing it.
14. Change a sprint length regularly to meet deadlines.
15. Not include QC (aka test execution by Testers) within sprint to get more coding done. In fact, this is frankly the worst practice of all. Also, by the way, there is no “them and us”.. you are all “Developers” if you are being part of development hands on.
16. Blame Scrum for our own failure to improve, which Scrum has exposed.
17. Think of Scrum Master or Product Owner – as a Project Manager.
18. Think Scrum helps in delivering faster. It’s not about fast delivery, it’s about knowing if we are doing the right thing. Doing the things right (good practices) is actually not even mentioned on Scrum at all.
19. Agree to work on items which are not part of the sprint. You are only screwing with yourself.
20. Allow PO to make changes on sprint backlog
21. Allow Development team members to make priority changes on Product backlog.
22. Allow Scrum Master to touch any backlog or make changes in the absence/permission of the respective owner.
23. Allow Scrum Master to get daily update on “what have you been doing? I saw you chatting more than working”
24. Allow Product Owners to add “stretched targets”, in case you run out of work.
25. Say “We are developers. We like to code and we hate when we are invited to a refinement meeting. It’s not our job.” – Yes it is, if you are in a Scrum team.
26. Assuming a Scrum Master is your “Master” – Read Scrum Guide v2016.
27. Commit to more work on planning and fail to deliver, creating distrust with a permanent damage on expectations – Commit less, make sure you are capable of finishing it. If you have free time, let PO know so he/she can add more work for you – Pull it in, you are controlling the work intake while making stakeholders happy.

Have you came across more anti-patterns of Scrum like these? Feel free to add a comment and it will be added in this list crediting you.