Scrum: Lessons Learned

It is a year as we have started using Scrum as project management framework. At that time I was starting with a startup company and it was on me to decide and propose next steps. Somewhere at that time I read Scrum and XP from the Trenches and found implementing scrum web site. For me decision was clear. Most of the colleague had some experience with "kind of" agile software development. Unit testing, CI, SVN has been part of life. But Scrum, iterations, user stories have been something new and something we had to learn. Although I have studied lot of books we started with baby steps. Today I believe we are children but we have much more experience than year ago.

During our sprints we have made some common mistakes, we have made some less common mistakes and I will try to summarize what we have learned.

First let me shortly explain our situation. We are small startup company with number of projects. Therefore it is not possible to have consistent team size per project. Further on, very often we are not able to run more than two-three consequent sprints on the same project. Althout these are some Scrum pre assupmtations, I believe Scrum helped us a lot and we wouldn't be where we are if we would go without Scrum.

So what are the most important lessons learned so far:

• Product backlog - although it is stated in all books and articles we very often failed to have prioritized list of features to implement called product backlog. When you don't have product backlog you are never sure about your future steps. So, always have product backlog with features to be implemented.
• Product owner - when there is no real product owner, and this is unfortunately very often case in our situation, somebody else (product owner proxy) must take responsibilities of product owner. It our case it is me (playing role of developer, scrum master and product owner proxy).
• User stories - although Scrum does not explicitly requires to express requirements as user stories, we found out that user stories are the best way to express requirement. It is easy to prioritize them, it is easy to understand them and it is easy to know when user story is implemented. At the beginning we used more generic terms for describing what we want to implement. That got us into position of never ending requirements (requirements that are never implemented).
• Sprint planning - at the beginning we had short sprint planning session. We just listed what we want to implement without discussion. Consequence was that we didn't had common design understanding, we had different opinion of DONE. As we used longer sprint planning sessions (4-5 hours) those understanding got better.
• Unfinished user stories - do not let sprint to finish with not all planned user stories implemented. If this is happening too often somewhere you are doing mistake. Lower your velocity, make better definition of DONE. If team is used that sprint can be finished but not everything is implemented this will repeat again and again. At the end of the sprint everything must be implemented otherwise sprint is failure.
• Code quality - very often you want to finish tasks as soon as possible and therefore underestimating user stories. Then what usually happens is that at the end of the sprint code is not written with production quality and later on you have to return to that code. Actually what happened here is that you didn't finish user story. Therefore, give yourself enough time for user story implementation. Do not forget refactoring, discussions, integration tests, nice user layout and experience. Only if you satisfy all these requirements you will implement user story with production quality and will have potentially shippable code at the end of sprint.
• Estimation - even after a year, we are still making mistakes when estimating. We can noticed improvements but we are still unsatisfied. For this problem for us there is still not solution.
  

And for the end, remember, Scrum is team work. Scrum master is here to help and protect the team, no to command the team.