The top 10 most common Scrum mistakes:

I’m often asked what common mistakes Scrum teams often make. I have complied a list of the 10 most frequent issues I have observed. Read on for a closer look at common mistakes keeping teams from their potential!

1. No User Story - This is the most common mistake anywhere, anytime. A user story is a requirement for your application that can be done by end users without writing code. If it requires coding to deliver, then it's not a user story.

2. No Definition of Done (DoD) - It may seem obvious to define what is to be done, but what is the verification that it's been done? Each user story should come with a DoD. It should be something you agree on up front, and complete before starting any work.

3. User Stories are Too Big - They should not take more than one week (in ideal conditions). If they do, then you'll need to break them down into smaller pieces.

4. No Stand Up Meetings, or They are Too Long - A stand up meeting is generally done every day, and usually does not take more than 15 minutes. If it lasts longer than that then your definition of done is wrong (or the work itself is too complex), or there are issues with the development process. Do not allow people to use the daily stand up meeting as a water cooler event.

5. No Backlog Refinement - Backlog refinement is ongoing throughout the project, but must happen before actual work starts on anything specific. If you are starting development without having any idea of what you are going to do, it's probably too late. DoD for any user story, even the simplest of them, should be completed before you start anything.

6. Too Many Dependencies on Other Teams - Work with your team on the appropriate level of autonomy and independence on what they are developing. If you are not taking responsibility for your work, it can easily turn into a bottleneck to getting things done.

7. No Task Board - A task board is the concept of prioritizing your work by arranging it into columns based on the current state of development or completion. It's useful for keeping everyone aware of what's being worked on and what's coming up so they can help and/or prepare as needed.

8. Requires Manual Testing at the End - The requirements phase should have included the testing for each user story. If it does not, then you have missed something. Automated tests are great for regression testing, but at the very least there should be some manual tests before submitting an application to production.

9. "Not my job" Attitude - Every member of your team is equally responsible for the success of your project. This responsibility should be shared equally among everyone during all phases, including testing and deployment.

10. No Documentation - Documentation is useful, and can be kept in a version control system. It's necessary for the entire team to understand and agree on what it takes to complete user stories.