I have believed in using Scrum as a software development methodology since I first were introduced to Scrum back in 2005/2006. After a while I took the ScrumMaster certification (CSM) and started using Scrum as the preferred development methodology. During this time Scrum was getting very popular i Norway. It had become a buzz word and projects were either using Scrum or talking about using Scrum.
The majority of projects that I have been involved in after 2006 have been using Scrum or at least been highly influenced by Scrum. During this period of time I have found my preferred way of using this methodology. In this post I will talk about how I like to use the tools provided by Scrum. This is not a guide on how to use Scrum but more me telling what works for me.
The image above shows the Scrum life cycle:
- You have a product backlog defining the product to be developed.
- Then you have a sprint planning meeting, choosing some tasks from the product backlog resulting in a sprint backlog
- You start working on the tasks in the sprint backlog for a sprint that should last between 2 and 4 weeks.
- Every day you have a daily Scrum meeting were all team members answer three questions: What did you do yesterday? What are you planning to do today? Do you have any problems?
- At the end of the sprint you have a sprint review were you demonstrate the result of this sprint
- After the sprint review you have a sprint retrospective which is only for the team members and ScrumMaster discussing what went well and what to improve in the next sprint.
- The sprint is over and you need to plan the next sprint (back to point 2). When the product backlog is empty the product should be ready for shipping or at least testing.
Most of the projects I have been involved in have been quite small projects estimated to 500 – 3000 hours with 3-5 team members. So what works for me in those projects might not be the best way to work on larger projects.
I like best to work with sprints that lasts for 2 or 3 weeks. I have also tried having 3 weeks sprints were the last week is a “lazy” week. By this I mean that the last week were used for testing, bug fixing and completing tasks that couldn’t be done during the first two weeks. This worked very well for that project because after every sprint we shipped the sprint results to their QA-department, so during the last week we were often fixing or changing functionality from the previous sprint. This is way better than to start doing this at the every end of the project and you have to start working with code developed several months earlier. It’s much more effective to be able to do this just a few weeks after the code was produced.
When I took the Certified ScrumMaster course, Kane Mar was the couch and he did a really good job couching and teaching us how to use Scrum. You can read his blog here. He also taught us how to use ScrumWorks from Danube Technologies to administrate the Scrum process. I find that ScrumWorks is a great tool that replaces the old Scrum board with post-it notes.
The screenshot above shows the main view in ScrumWorks with the product backlog at the right and the sprints with the sprint backlog at the left. I often use this tool to predict when the project will be completed. I add the sprints and populates them with items from the product backlog, this way I can see how many sprints we need to release the product. This is just an indicator since the sprints are not “officially” populated and committed before the sprint planning meeting.
I also like to work with projects that have a product backlog that is not final and only containing a roughly specification for the product. This way the product backlog can evolve during the project. Isn’t that what agile software development are all about?
The image above is the sprint detailed view in ScrumWorks. Here you can see all task for this sprint and the status on the tasks, you can see the sprint main goals and also the sprint burndown chart. This is the view I use when I’m working on a sprint and the main view is the view I’m using when I’m planning a sprint or a complete project.
I like to look at Scrum as a great toolbox containing several tools that can be used in a project. I think that you do not need to use all the available tools, but you can pick the right tools for your project. I guess that Kane Mar would call this “Scrum but” meaning using Scrum, but not using it completely by the book.