Where you mostly go wrong with SCRUM

By seen over few years for teams practicing SCRUM in various projects, I’ve noticed few common mistakes some teams do. I thought to spend few minutes to make a quick post; because they may help you too.

1. Too quick in Product Backlog planning
Seen this problem over and over again. In some of the projects you need few rounds of PB pre planning, be ready with stories, wire frames, UI flows , sometimes even the domain models. But there are many times those Product owners and teams rush in to PB estimates without having what’s needed to have.

2. No common understanding about the meaning of “Story points”
What does the story points really mean to you and your team members? ask each member of your team individually and you will be surprised.

3. Talking vertical, Thinking horizontal
This is very common with people who fall from waterfall to agile. Define a sprint called 0 and do all design upfront?

4. No release plan
Where is your release plan to the customer? Do you do a release after 1 sprint? 2 sprints? How many scrum teams do upfront release planning I wonder…

5. Sprints in different time durations.
If you have 10 days sprints.. go for 10 days sprints.. I cant still understand when I hear teams telling last sprint we had for 10 days.. but this sprint we will do 30 days.. then how do you ever calculate the velocity of your team and predictions for future sprint burn rates? This is why I need a release plan separately.

6. Getting wires mixed up about what testing means in agile teams
Ive seen this situation.. can you ever think of a scrum team where developers stop work and wait till the tester test their software within the sprint..? if you have more testing time, the team should do testing instead waiting.

7. No feedback taken after the customer testing those iterative releases.
You keep on releasing.. But if there is no one in the other end, who will test your iterative working software releases and give you a feedback, then there is no meaning to the iterative releases.. because you are anyway not too sure whether you comply with your customer requirements or still developing your own fantasies.

8. Scrum master role
Google and learn..

9. Misreading the burn -down..
What does burn down really mean to you? Take a good look at it.. again ask the question from all your team members.

10. Not using the Engineering principles to align development with SCRUM
Engineering has evolved a long way to adapt to agile way of developing applications, many test tools, code quality tools, tools which helps continuous integrations and lots of wiki tools are out there. Do you take the real use of them?