Scrum is an agile framework. Now, what is an agile framework? Basically, it’s set of rules/standards to follow for creating something else.
Scrum is commonly used to make software, and it’s something that’s been around for years and used in a lot of different companies.
Scrum contains all of the following elements:
- Scrum Framework
- Scrum Values
- Scrum Roles
- Scrum Events
What is the Scrum Framework?
Why explain it when I can show a picture:
Let’s walk through this a little bit regardless.
You have your product’s backlog, which is typically a set of requirements to complete and finalize a thing, which could be an application, database, etc.
The items in the backlog are then organized / compartmentalized inside of sprint planning, which is an allocation of time or resources for a part of the backlog (or all of it, if your backlog is small).
From there we go to the sprint backlog, which is the subset of the product’s backlog that was organized to be completed in the sprint.
The sprint is then assigned to a scrum team, which meets daily to complete the items from the sprint backlog.
After the completion of the sprint’s backlog, or the time runs out for completing items in the sprint, a sprint review is performed.
From here three things happen:
- A sprint retrospective is performed, which is basically going over what was completed, what wasn’t completed, and how much time it took.
- A new sprint is planned, taking into considerations the leftover items from the last sprint, how much time the last sprint took, etc.
- With the new sprint, the release is incremented
What are Scrum’s Values?
If I had to put a price on it, it would be priceless. The amount of time and organization that the scrum agile structure saves is un-measurable.
Here are Scrum values, taken directly from their site, please drill these into your mind, as it helps keep the team structured and frankly, makes everyone get along:
What are Scrum Roles?
There are 3 main scrum roles, and I will briefly describe each of them:
1. Product Owner
The Product Owner should also be synonymous with “Backlog-Guru” and should only be ONE person. Their responsibility is to organize the backlog, requirements, goals, and missions.
Another primary goal is making sure everybody on the scrum team understands what is going on. This is very important.
Other scrum roles may contribute to making sure everybody on the scrum team understands what is going on, but ultimately the product owner is the one who remains accountable.
Good Product Owner:
- Clear, concise tasking and descriptions of backlog
- Clear, concise ordering of backlog
- Clear, concise backlog visibility
- Supports scrum team and scrum master
- Almost always available for clarification or questions
Bad Product Owner:
- Makes scrum master or scrum team do everything
- Badly described tasks, one word descriptions on backlog items
- Is never available, misses key milestones in the scrum framework
- Doesn’t apply scrum values
2. Scrum Master
The scrum master should be your best friend on the scrum development team. They keep everyone sane, mostly by promoting scrum, and its values, practices, and rules.
The scrum master does mainly two things:
- Services Product Owner
- Helps with backlog management and sprint planning
- Organizes scrum events
- Helps ensure goals and values are met
- Services the Development Team
- Basically, the software team’s “Coach”
- Helps to organize and assign team members to tasks, due to having a closer relationship with the team
- Helps with completing backlog items and reviews of completed items
- Helps team to understand values of scrum
Good Scrum Master:
- Familiar with product owner’s backlog items and goals
- Demonstrates and helps the development team understand scrum values
- Often helps / completes backlog items and review processes
- Experience with the baseline of the product being created
Bad Scrum Master:
- Only works on tasks instead of being a leader
- Only is a leader and never works on tasks
- Doesn’t demonstrate scrum values
- Misses meetings or fails to organize scrum events
- No experience with the baseline (Example, the team is creating a C++ application and the scrum master is a hardware expert…that’s great, but it doesn’t fit)
3. Scrum Developer
A Scrum Developer is the person who is responsible for actually completing the backlog items and completing tasks, with the support of the scrum master and product owner of course.
A Scrum Developer should have heavy familiarity with the entire baseline, there should be as little “gurus” of elements as possible. Every scrum developer on the team should be able to take any task on the backlog and complete it. Sub-teams should be advised against as well.
Obviously, this is not always the case, but the values of scrum should push towards every member being familiar and capable with the baseline in order to complete any task that might come their way.
Also a good scrum team should be at least 3 to 8 people, not including the scrum master or the product owner. Less than 3 and now there’s barely any interaction. More than 8 and you practically have an entire company. In this situation, it’s best to declare an additional scrum master and split to another scrum development team.
A Good Scrum Developer:
- Follows and understand the Scrum Master and Product Owner’s backlog, goals, and values.
- Follows and understands scrum values
- Self-sufficient and understands the baseline
- Knows when to ask questions and isn’t afraid to, doesn’t ever “wait on a response”, continues to try and make progress
A Bad Scrum Developer
- Doesn’t follow or recognize the Scrum Master and/or Product Owner’s backlog, goals, or values.
- Doesn’t work well with others
- Constantly needs “hand-holding” on tasks
- Refuses to ask for help or works too much without guidance
What are Scrum Events?
There are 5 Scrum Events, as defined in the framework above, we’ll go through a brief description of each of these.
- Sprint
- Sprint Planning
- Daily Scrum
- Sprint Review
- Sprint Retrospective
What is a Sprint?
A Sprint is an allocation of time and resources, typically one month or less, in which a set of backlog items and/or goals are set to be completed, which is then defined as a release.
For example, you can have backlog of tasks, which are a list of tasks inside of a tasking architecture such as JIRA, and then those tasks are assigned to a release, which ultimately is the sprint.
What is Sprint Planning?
Sprint Planning takes the Sprint that was previously created and does just that, it plans it out.
Sprint Planning should be performed by the entire scrum team; Product Owner, Scrum Master, and Scrum Development Team.
Sprint Planning should be no longer than 8 hours and is organized by the Scrum Master, and is demonstrated to the Scrum Development Team.
This is where the items from the main Product Backlog are organized into the Sprint Backlog.
Items in the Sprint Backlog are organized into goals, which have a definition of done, capacity, complexity, and forecasts.
What is Daily Scrum?
A Daily Scrum meeting is a progress update and inspection meeting that is held everyday of the sprint, and within the scrum members (Only product owner, scrum master, or scrum development members should attend). It can identity problem areas, make quick decisions, and promote awareness across the team on what everyone is doing (or not doing).
A Daily Scrum meeting is usually time-boxed to 15 minutes, but can be slightly larger dependent on the number of Scrum Development members.
Some key elements to remember / acquire when attending a daily scrum meeting:
- From my tasks, what did I work on / complete yesterday?
- From my tasks, what problems were created, resolved, etc.
- From my tasks, what do I plan on working on / completing today?
These sound very similar to the attributes of a status meeting, but the importance is that the developer should be self-organizing their own tasks, and be held accountable for each of them, instead of expecting others to resolve them. Also, there should be obvious transparency of what is happening in your completion of your tasks.
What is a Sprint Review?
A Sprint Review is a Scrum Event that is held at the end of every Sprint. It’s an event that helps to inspect the previous sprint and the assigned backlog items’ status; percentage of completed, still in progress, or not started.
A Sprint Review is typically time-boxed from 2-4 hours, depending on the length of the sprint.
The attendees of the Sprint Review should be the whole Scrum Team, and sometimes key stakeholders that the Product Owner can include. Each member discusses what was defined as done, what problems occurred, how problems were resolved, and if there were any decisions that were decided upon.
Sometimes a demonstration of a product or a review of documentation is provided depending on the tasks implemented.
Items for the Sprint Planning are organized, including the timeline, budget, potential capabilities of the previous sprint.
What is a Sprint Retrospective?
A Sprint Retrospective (commonly referred as a Sprint Retro, for short) is a Scrum Event used for the inspection of the previous sprint in regards to the next sprint.
During the Sprint Retrospective all of the scrum team members discuss:
- What went well in the previous sprint
- What could be improved
- What will we commit to be improved
Some bonus elements include:
- What should we keep doing?
- What should we stop doing?
I hope this guide helps you understand the basics of scrum. Keep in mind that sometimes these elements change.
Coding Timplates 