We’re using SCRUM for our development process for about three years now, at least we thought so. Almost a year ago I attended a SCRUM Master training hosted by Jeff Sutherland. When he showed us the the Nokia test (http://jeffsutherland.com/scrum/nokiatest.pdf) and hearing him talk about organizations implementing “scrum but”, the essence of SCRUM became clear to me. Returning from the training with a big list of improvements for our SCRUM we started to implement a real SCRUM.
Basically a good SCRUM can be implemented by implementing the following image:
Copyright: Jeff Sutherland 1993-2009 (http://jeffsutherland.com/scrum/PracticalRoadmapMunich20091020.pdf)
Ready
Start with a good product owner who is able to get user stories in ready state. For more info on user stories: http://en.wikipedia.org/wiki/User_story. A user story will help you to cut functionality in small pieces enabling both developers and customers to talk about the same information, without big requirements documents which will give developers a hard time reading it and product owners a hard time maintaining it.
A user story should be small so they can be completed within one or two days (preferably) and should contain acceptance criteria so both developer, QA guy and customer know when a user story is finished.
Next to a well defined user story it is really important to size the user stories. Please don’t size based on hours as this is way to precise and can be different per developer. And SCRUM is all about a team commitment. But is really important to measure the number of user stories a team can do in a sprint so some measurement is needed. We use planning poker in combination with the well known Fibonacce range: http://en.wikipedia.org/wiki/Planning_poker
So a user story is basically ready when it is well described with acceptance criteria and sized. When having a set of ready user stories they should be prioritized on the backlog to allow the team simply moving to the next user story from to to bottom.
Team and impedements
The primary goal of the team is basically three things: helping the product owner to get the user stories ready, implementing user stories and identifying and removing impedements. If an impedement cannot be removed by the team the SCRUM Master will try to get the right people to get it fixed.
Done
A user story is done when it meets both the acceptance criteria and the more general definitions of done. The acceptance criteria will define how the functionality works and the definition of done will cover a more general acceptance criteria, i.e.: code conventions, unit tests, performance requirements, db scripts, etc..
Make sure the user story is tested by a QA guy on a deployed environment and not on a developers machine. Our test will be deployed every night automatically and if necessary upon request after every continuous build.
Burn down on user stories only, to make sure that your really have built some real value. No customer will be happy with a set of domain objects only, its about the full stack.
Velocity
When everything mentioned above is in place focus on velocity. This the best measurement on how the team is performing. Ask yourself everyday about the thing that can be blocking for reaching a higher velocity. This can be as simple as having slow development hardware but can me more complex as having a backlog which is not in ready state. The more a team performs the more it will face issues which will block its performance so focus on every minor detail!
Finally
So SCRUM is actualy quite simple: A ready backlog, a team focusing on implementing the backlog and removing its impedements and a QA guy assuring a done user story. Of course this is only a summary and much more can be said on every topic but I do like it to have an overview in my mind an now on my blog. Thats why I really like the image above.
I didn’t talk that much on retrospectives, sprint planning and review. Maybe in a next post.
as developers can totally focus on the domain logic and its unit tests and worry about the rest later. Another and not the least advantage is that the code really reflects the model as designed on the white board.
