What is Scrum?

I am going to make an attempt at describing what is Scrum as concisely as possible. I won’t get into the details of it, but hopefully, I can provide you with enough information that you can gain an  understanding of Scrum. Essentially, Scrum is a software development framework for developing a product in an iterative fashion with teams continuously improving the product.

Now let’s say that you are developing a product. This product will contain a variety of features. These features represent the end users’ wishes and they are also known as feature stories. A collection of them is called the product backlog. Basically, it is a list of things that the end users desire to see in the product. You and your team will then need to determine which feature stories need to be put into a particular release of the product. This new list is called the release backlog.

The structure of your team will be similar to what we have seen in other project development methodologies having developers, testers, executive sponsors, and customers. In Scrum, there’s two additional new roles for the team: product owner and scrum master. The product owner is the representative for the clients and advocates for the right features to be included in the product backlog. They are like the coach of a sports team where they set the future direction of the product. The Scrum Master does everything to ensure that the project is moving along smoothly until it reaches the finish line. They are responsible for arranging the team meetings, keep an eye on the progress of the work, facilitate release planning, and help remove inefficiencies for the team.

Your team will then estimate the time to produce each feature story and the total of all the estimates is how long it would take to complete the release. Estimating the time it takes to complete a feature story is an important step when planning software projects. A variety of factors can be used to determine the time it takes to complete a task such as personal past experiences, experiences of others who have done similar tasks, complexity of the task, and comparison to other similar tasks. I recommend having some kind of system where the work is estimated in a unit of time based on their size. As an example, features that can be completed in day can be estimated in hours such as 1, 2, 4, or 8 hours. Features that can take more than a day to complete can estimated in days such as 2, 3, 4, or 10 days. Large features can be estimated in months such as 1, 2, 3 or 6 months. However, for these kind of features they will have to be deconstructed into much smaller pieces in order to be able to actually start work on them.

Therefore, the release backlog is a list of prioritized and estimated feature stories. The next step is to take this release backlog and divide it up into manageable parts of the project called sprints. The main intent of the sprint is to get a part of the release backlog to a completed state. Each sprint represents a short-duration milestone and they can range from a couple of days to thirty days. The shorter the release cycle then the sprints will be shorter. Typically, you can have two or more sprints in a release cycle. The tasks that are in a sprint are also known as the sprint backlog. Every day, there are fast paced, stand up meetings conducted as a means to communicate information to everyone on the team. Everyone at these meetings report their progress and raise attention to any obstacles that they may be experiencing. The idea is to raise early awareness of any difficulties and, collectively as a team, figure out a solution in order to stay on track with the sprint’s completion date.

How does one monitor the overall progress of a sprint? How do you know if your team is progressing at a pace that will ensure meeting the target completion date? In Scrum, burndown charts are used to monitor the progress of a sprint and predict when the sprint will be completed. The chart shows the amount of work left to do (vertical axis) versus the time (horizontal axis). The slot of the chart is called the burndown velocity which is the average productivity rate for each day. The burndown chart visually can help your team determine whether your project is on track and, if it is not, then you know to make the appropriate adjustments to get back on track.

Upon completing your project, an important step for your team to do is have a retrospective meeting. In this meeting, your team can discuss what worked and what didn’t worked. This way for the next sprint, you can work better on your tasks.

I hope that without getting into the details that I was able to provide you with a high-level overview of the Scrum development framework.