In this article, we will be covering a wide range of core Scrum concepts, like

What are Product backlogs?

Roles and responsibilities of a team

How do Sprints work?

What is the purpose of Release?

An overview of burndown charts

How does Daily Scrum work?

A brief overview of the tools

The purpose of a review

So get ready for a barrage of information.

User Stories #

Let’s say we want to build an “Online Banking App”, and call it a product. Customers, executives, other members of the team, and even developers request all kinds of features for this product. Features are written from a user’s perspective in Scrum. User stories are therefore known as features.

Product Backlog #

The product backlog is called when all of these user stories are gathered together. Backlogs are another way to think about products. Consider it a wish list of everything that would make this product great. As soon as we have our wish list or product backlog, we need to begin planning which specific user stories to include. We will incorporate these user stories into a particular release. We’re getting ahead of ourselves. Let’s take a step back and first learn about the scrum team.

Scrum Team #

In order to build this product, as a team, we should have one or more people who can play multiple roles. Our first priority is to get her. Her role is of the product owner, who assists in ensuring the right features are included in the product backlog, representing the product’s users and customers. The direction of the product is set by her. This guy is needed, then. The Scrum Master’s job is to ensure that the project progresses smoothly and every member of the team has the tools they need to succeed. In addition to setting up meetings, he monitors the work being done and facilitates release planning. The title project manager sounds a lot like him, but it’s so boring. So, let’s spice it up and call him a Scrum Master. Similarly, the rest of the team plays a similar role in other development processes. It’s these guys who build the product, these guys test it to make sure it works. It’s used by these guys, and hopefully, they pay for it. Generally, these guys get in the way, but you can’t build a product without them.

Release Planning #

Let’s get back to the release planning. As part of planning a release, the team starts with the product backlog, they identify the user stories they would like to include in this release. The user stories are then added to the release backlog. In the next step, the team prioritises the user stories and estimates the amount of work required to complete them according to each item. Large user stories can sometimes be broken down into smaller, more manageable chunks. All the estimates combined provide a rough idea of the total amount of work involved in completing the release.

Understanding Estimates #

Here’s a quick note about estimates. Good estimates can be created using a variety of techniques. There are some people who prefer estimating in story points. Sadly, story points don’t answer the question, “What is the timeline for my project?” It has been our experience that estimating work in hours is the best method, it is important to use some standards when estimating. Things that take less than a day, for example, it will take 1 hour, 2 hours, 4 hours, or 8 hours to complete. Each item will fall into one of those buckets. For example, there will be no 3-hour estimates. Items that take 3 hours would fall into the 4-hour category. The estimated time for larger items will be two days, three days, five days, or ten days. All estimates in between will fall into the next larger bucket. It is similarly estimated in months for extremely large items: 1, 2, 3 or 6 months, in reality, such items will need to be substantially broken down, before the work begins. We’ll get back to these estimates shortly. For now, let’s go back to the release backlog.

Release Backlog #

This is the Release Backlog. Based on the prioritised user stories and the estimated amount of work, we are now ready to plan several sprints to complete the task. Teams tackle manageable chunks of work with sprints, which are short-duration milestones to get to a shippable state. The duration of a sprint can range from a few days to 30 days depending on the release cycle of the product. A sprint should be as short as possible based on the release cycle.

Sprint Backlog #

In a given release, you should have at least two to a dozen sprints. At this point, we can divide our release backlog into several chunks and call it a Sprint backlog.

Sprint Planning #

The most important thing to remember about sprints is that each sprint’s goal is to get a subset of the backlog to a shippable state. By the end of each sprint, you should have a thoroughly tested product with all the features of the sprint, 100% complete. Due to the fact that sprints are a concise but realistic representation of parts of the product, a late sprint finish is a good indicator that the project is not on schedule and that, something needs to be done. Therefore, it’s extremely important to monitor the progress of each sprint very closely.

Burndown Chart #

In order to monitor the progress of each sprint, you should use a burndown chart. It is the burndown chart that makes Scrum so popular, one of the best tools for project visibility to ensure smooth progress. A day-by-day measure of the amount of work that remains in a project is shown by the burndown chart. This graph shows how the amount of work remaining bounces up and down on a daily basis. However, it tends to zero in the long run. The burndown chart provides historical information, so it is easy to see if the team is on the right track or not.

Burndown Velocity #

The slope on the burndown chart is known as Burndown Velocity, the average rate of productivity each day. Let’s see an example of how to predict the team’s productivity on a typical day. If the team completes approximately 35 hours of work on that day, then an estimate of the sprint’s completion date can be calculated by looking at the slope. It can be used to predict the entire release completion date as well, depending on how much work remains. The burndown velocity helps us to compare our actual velocity and projected completion date to figure out the changes we need to make to finish our project on time.

Project Timeline #

The burndown chart helps us to get a realistic impression of our project timeline. The information presented by the burndown chart will be helpful for any team member, product owner, or product executive to know whether the project is on track or it’s going to be late. In case late, the team can then make the necessary adjustments to bring the project back on track. First, let’s talk about where the data for this extremely useful burndown chart come from. As we have learned earlier, during the release planning process, an estimate was created for each user story in the release backlog. For each sprint, these estimates represent the total amount of work to be done to complete the sprint. As each team member progresses on one or more user stories, they update the amount of time remaining on each user story they worked on. Therefore, the total time remaining on a sprint’s group of user stories changes daily. Hopefully, going downwards until it reaches zero by the end of the Sprint. By using the burndown chart, the remaining work data can be visualised. The reason this is so brilliant is that it communicates a massive amount of information in just a few seconds.

Daily Scrum #

The Daily Scrum is one of the essential tools that a team can use to ensure that communication flows freely between members of the team. And as the name suggests, it takes place every day. Basically, what we are trying to achieve here is to have fast-paced meetings called stand-ups where members of the team are asked to give a brief summary of the work they have completed since the last scrum meeting, as well as any obstacles that they may encounter along the way. By meeting daily, the team ensures that they are always up to date and in sync with one another. If any major issues are identified, they are addressed as soon as possible.

Sprint Retrospective #

At the end of each sprint, as each sprint comes to a close, there is no doubt that it is important to have a Sprint Retrospective meeting. There should be a place for the team to reflect on what went well and what could be improved. There is no doubt that Scrum is a flexible and agile method for developing software. For each team, it is a constant process of improvement and tweaking that needs to be continued. You now know all the essential concepts you will need in order to use Scrum within your team. But wait a minute, there’s more to it than that. Do you know any tools that you can use to implement Scrum?