Scrum Framework is a relatively new buzzword in the market that is now getting as much attention as terms such as NoSQL, Hadoop or Cloud Computing.
Scrum Framework is a simple and efficient Agile methodology to manage software development projects with an uber-cool name. The history of Scrum Framework dates back to October 1995 when Jeff Sutherland and Ken Schwaber (the original developer) worked together at Easel Corporation and initially conceived the idea of Scrum backlog – a framework for managing and developing Agile projects. The first official release came out in February of 1997 after which it became popular among IT industry professionals everywhere.
Since then, the term Scrum has evolved beyond just being a lightweight project management tool into something that offers several advantages over traditional
What is Scrum?
Scrum is a framework for managing the work of an agile software development project. The goal is to have regular, sustainable productivity. To do so, all team members meet on a regular basis to create more valuable products together with changing the workflow based on results achieved. Watch this quick video to understand how scrum works.
Scrum is actually based on two simple concepts: the product backlog and the scrum board.
The Product Backlog is a list of all features, improvements, bug fixes that need to be added or performed in the product during the development cycle. This list is prioritized by business value so that each user story has an order of importance. This list is practically never-ending, with new user stories being added regularly through the entire product development cycle.
A Scrum Board is a simple tool in which each column represents one of the scrum roles, while each row represents a different stage of development. If you are looking to make your own Scrum Board consider using Trello and the following guide on how to set it up.
The Scrum board columns represent different stages of development.
Backlog – The Product Backlog column contains each user story inside it. This column will never be empty because new user stories are added regularly throughout the product cycle. Doing so allows you to see all the work that is being done for a particular user story and if it’s completed or not, instead of seeing everything as a whole at once where you might miss something that was completed but then changed because of an update or defect found during testing. Stories can be moved from one column to another by dragging and dropping them where they need to go, instead of writing a date in which they were completed, this allows for a more flexible system of tracking work.
h – This column is for showing what order the user stories are in and is used mainly to help with scheduling out which story needs to be worked on first. The numbers going from 1-4 go from where the user story fits into the product backlog as a whole, not necessarily when it was added.
The Product Backlog column contains each user story inside it. This column will never be empty because new user stories are added regularly throughout the product cycle. Doing so allows you to see all the work that is being done for a particular user story and if it’s completed or not, instead of seeing everything as a whole at once where it can be easy to get lost or confused very quickly.
The Sprint Backlog column has the user story broken down into what exactly needs to be done to accomplish that user story, who is doing it, and if there are any dependencies on other items before this particular item can be worked on. This includes enough information so that you know where you are at all times with your implementation of the user story.
The Build column has each step needed to build the game itself coming together in one place. The idea behind this is that traditionally if developers had bugs then they would need to look throughout their code for everything that was affecting that bug; now they only have to look inside whichever task is currently open (because it’s due either to a merge or because they are actively working on it).
What we see here is that we’ve implemented step 1 for #5 and step 2 for #7. We also have ideas about steps 3-5 for both these user stories, but those were not ready at the point this task was started.
The reviewer column is anyone who has the responsibility of reviewing work before it gets accepted into the main development branch (normally QA or someone like myself, depending on how you’re set-up). By putting specific names in each cell we can ensure that we follow up with people as necessary to keep the pipeline moving smoothly. For instance, I might need to remind a developer that his stuff isn’t merged and ask him if he needs help with anything. This workflow makes it easy to know who needs to be involved and when.