Let’s start with the most popular of the two.
One interesting thing to note regarding Scrum is that it was developed in the early 90s and some of the initial founders of Scrum were part of the group that created the Agile manifesto.
The key principle regarding Scrum is that teams functioning as one unit is a key factor of success.
When using Scrum as a framework for software development the team comes together to prioritize the required work and sets short term goals for the work that needs to be completed.
There are 3 main roles in a Scrum team with each role carrying specific responsibilities.
The product owner owns and manages the development backlog.
They ensure that it is prioritized with the most important items at the top and the least important at the very bottom. And any items which will not be addressed are removed.
User stories clarify the goal of the intended work and the value that the end user will receive.
Acceptance criteria are written to clarify when the specific piece of work meets the definition of done.
Check out our guide on the 9 Common User Story Mistakes Most Product Managers Make.
The product owner is generally used as the term for the product manager in a Scrum team. They make the decisions on which items will move from the development backlog to the sprint backlog to be worked on in the sprint.
A scrum master’s main responsibility is to facilitate the Scrum processes.
They ensure that everyone understands how things work, what Scrum means, and ensures that the processes are being followed. Not just within the Scrum team, but with the entire company.
The Scrum team consists of all of the other members of the team who work on the tickets that come from the backlog.
This includes the designers, developers, and the Quality Assurance team.
Scrum has 5 main rituals that are followed each sprint to facilitate the Scrum process.
You can also think of these as 5 main events that take place every sprint.
A sprint is a period of time in which the team works towards accomplishing a specific goal. It is from when the work is planned to the point that the stated work is completed and released.
Sprints vary in length depending on the company.
While companies have 2 week sprints, sprints can vary from 2 to 6 weeks depending on the company.
The Scrum team gets together at the beginning of each sprint to plan the work for that sprint and the expectation is that at the end of the sprint there will be additional improvements that have been tested and made ready for release for the benefit of users.
The 5 Scrum rituals are:
Daily stand up
Before we dive deeper into each Scrum ritual we want to shed some light on the development backlog. This is where “stories” come from.
The development backlog is a centralized list of prioritized tickets that include stories, tasks, spikes, bugs, and technical debt.
Stories: New features or enhancements to be added to the product written in a specific format
Tasks: Things that need to be taken care of by someone on the team. For example updating the copy on a specific page
Spikes: Items that someone on the team needs to further research or investigate to inform future decisions
Bugs: Issues within the product that needs to be fixed
Technical debt: Rework that needs to be done for the product due to an intentional past decision
The development backlog is prioritized and maintained by the product owner.
Good product owners regularly review their development backlog and nurture it to ensure that the highest priority items are the most visible, near the top, while those lower in priority are the least visible, near the bottom.
If you want to have an effective backlog then follow the DEEP model. This is an acronym that clarifies how a development backlog should be managed.
Detailed: Each item contains the required details and has enough details for members of the Scrum team to work on them independently
Emergent: The backlog constantly evolves. Items are added as needed and likewise removed as needed. The work is flexible and can evolve based on the team’s needs, business needs, and/or customer needs
Estimated: Upcoming items should have estimations tied to them so that the team can accurately plan their work for the sprint(s). And those items with a high level of estimate are broken down into smaller pieces of work
Prioritized: Backlog items are ranked with the most important at the top and the least important at the bottom. This way as work for the sprint is complete then the next highest priority item(s) can be pulled in
Here are some other things to keep in mind when managing a development backlog:
Review the backlog on a regular basis and ensure that it’s prioritized and the tickets are clear
Consider grouping items on the backlog into short-term vs. long-term
Remove items which will never be worked on from the backlog
Surface related valuable information for each ticket on the backlog for the benefit of your team. For example surfacing the specific customers that are requesting the feature on the main view. This can be done with a development tool like Jira
Now that we have a better understanding of the development backlog let’s now discuss the 5 Scrum rituals in detail.
This ritual is led by the product owner (the product manager in a Scrum team) and the entire team participates.
The purpose of this meeting is to ensure that all of the tickets that will go into the sprint are ready for development.
In this meeting the product owner will review the tickets, user stories and acceptance criteria with the team, and ensure that the team is comfortable to start working on them.
Story points may also be added to the tickets during this meeting.
A story point is a number that indicates the level of difficulty for fulfilling a piece of work.
While it is not meant to denote the duration it takes to complete the work there are many teams that use them for this purpose.
Remember, Scrum can be flexible when needed. It does not have to be, nor should it be, treated as rigid as Waterfall.
One common method that’s used for setting story points is the Fibonacci sequence. The scale goes: 1, 2, 3, 5, 8, 13, 21, and so on with each increase in the scale denoting increasing difficulty in the work at hand.
You can read more about this estimation method here.
Some teams decide to assign story points during this meeting while other teams may give their team the needed information for each ticket and then allow them to follow up later with the story points.
This is beneficial especially if they have some research to perform or need to review the codebase to provide more accurate estimates.
How does a team know which number to apply to a ticket?
They determine this based on their past experience. However, keep in mind that it is an estimation.
The sprint planning meeting is run by the scrum master and the entire Scrum team participates.
Prior to this meeting all of the tickets that are stated to go into the next sprint (meaning they are prioritized at the very top of the backlog) should be fully understood by the team and have story points attached to them.
The main purpose of this meeting is to define the work that will be performed in the sprint. This includes setting the sprint goal.
The sprint goal comes from the product owner with input from the team.
Once the sprint goal is defined and the sprint begins the entire Scrum team's focus and energy for that sprint goes towards accomplishing the set goal(s).
Along with setting the goal the team will determine which tickets they will work on and the total workload based on the total story points.
Check out our actionable guide for product managers to run effective sprint planning meetings remotely.
The end of this meeting formally begins the sprint.
Another term for daily scrum is daily standup.
These are daily meetings that generally occur in the morning with the entire scrum team.
In these meetings each scrum member provides a summary of their work answering three questions:
What did you accomplish yesterday?
What are you focused on today?
Do you have any blockers?
A blocker is anything that is preventing someone from continuing their work.
These meetings are meant to be quick and informative. Each member of the team provides a quick update giving everyone on the team visibility on what each person is working on and how their work is progressing.
Team members can follow up with those who have blockers after the meeting to provide assistance.
One of the common reasons why these meetings take place standing up (hence the term “standup”) is because they are meant to be quick.
People generally don’t enjoy standing for long periods of time so if everyone is standing during these meetings then they are more likely to be brief.
I have participated in standups that took longer than 20 minutes because everyone was sitting. Rather than being brief and to the point team members would also get into deep discussions on points mentioned by others
The Scrum master should take note of this and put a stop to it. Detailed discussions should happen after the meeting.
Daily standups are not specific to Scrum. They can take place in Kanban and Waterfall software development as well.
While many teams have these meetings first thing in the morning it does not have to take place at this time. Feel free to modify the time and format in a way that works for your team.
Some teams prefer to have the entire team meet in one central location in the office while others may decide to have everyone hop on a Zoom call. There are even some teams who simply type their standup notes in Slack.
Scrum is not meant to be super prescriptive like Waterfall. Remember the Agile values.
During the sprint the team performs the work required to meet the sprint goal.
They share blockers, ask for assistance when needed, and eventually reach the end of their sprint.
The sprint review meeting takes place at the end of the sprint. The main purpose of this meeting is to get feedback from main stakeholders.
The team also gets feedback from the product owner who tests the latest build to ensure that it meets the definition of done (all of the acceptance criteria are met).
If everything is acceptable then the product owner will give their approval and the team will then prepare for release. If there are issues that need to be addressed then they will be pointed out and the team may have some further work to do.
From this meeting the team will have a good understanding of what should be incorporated into the planned release and the product owner will define some items that should be transferred to the following sprint.
This meeting generally ends the sprint. The retrospective meeting which happens after this is a discussion on how this sprint went.
The retrospective meeting is when the entire Scrum team gets together to uncover ways to perform better as a team. Every member of the scrum team takes part in this meeting.
This meeting is run by the scrum master. Three main points are discussed regarding the recently completed sprint:
What went well during this sprint?
What went poorly during this sprint?
What action items do we need to take to improve moving forward?
The scrum master takes notes during this meeting, especially of the points mentioned for the last two questions.
When Scrum teams take the retrospective seriously they are able to improve their work and processes with each successive sprint.
Now that we have a better understanding of Scrum and how it works in detail let’s discuss some of its downsides.
Following Scrum can be tasking on product managers, especially when they don’t have a dedicated product owner that they work with.
In some companies product managers focus on product strategy while they have dedicated product owners to work with the Scrum team to translate the product strategy into delivery.
Without a scrum master the product manager will be busy addressing both product strategy and delivery work for the product.
Product managers will have various tasks to perform.
Along with refining the roadmap, working with stakeholders to support and enable them, regularly interfacing with customers, and reporting on strategic initiatives, while following
Scrum they will also be busy writing writing user stories and acceptance criteria, performing acceptance testing, and attending the scrum rituals while working with the scrum master to facilitate the scrum process.
This is not a downside of Scrum per say but rather on how some teams implement it.
Some Scrum practitioners focus more on the Scrum processes than on the individuals they work with and the goals that they set out to achieve.
As a result change is limited to better planning rather than working to ship valuable work quickly and obtain feedback. Process is beneficial however too much process can be detrimental.
It’s important to remember that Scrum is a framework. It’s not meant to be as prescriptive as Waterfall and it should not be treated so rigidly.
If and when certain rituals do not work for your team then feel free to modify them (with justification).
We have covered Waterfall, Agile, and Scrum in this guide. Now let’s discuss the second most popular way in which Agile software development is implemented.