Lets talk about Scrum. Not Scrum right out of the Scrum Guide, but Scrum in the real world.
Before we dig in, I must call out that the Scrum Guide is fantastic, and anyone practicing Scrum should know it. This article isn’t to take away from or shit on the Scrum Guide. Rather it’s to talk about my experience through the years using Scrum in the real world.
If you’re serious about Scrum and Agile, you should read the official guide. Or even better, become a Certified Scrum Master and really take Scrum for a ride.
Everyone’s mileage may vary, but here’s a quick rundown of Scrum throughout the past 8 or 9 years in my career. Or maybe more. I don’t know. The years just sort of run together now.
Scrum-diddlyumptious
We won’t go into incredible detail about Scrum in this article. However, it should provide you with enough information to start using Scrum on your projects, and provide a “go-to” place for Scrum teams to understand what is expected of everyone. This will focus on being a “realistic” view of Scrum, and less of the perfect world text-book view.
Scrum is an agile way to manage a project, usually software development. Agile software development with Scrum is often perceived as a methodology; but rather than viewing Scrum as methodology, think of it as a framework for managing a process.– Mike Cohn
Ok….great. But what does that mean?
Scrum is a framework within the Agile methodology. One of the key principles of the Agile Manifesto is “Individuals and Interactions Over Processes and Tools”. There are certainly processes within Scrum, but one should never lose sight of the “People First” approach in Agile. We want to stick to a framework, but not at the expense of people.
The Scrum Principles
There are 6 Scrum principles that are important to know. While these are what drives Scrum, at the heart of it is the focus on simplicity. Scrum can be difficult to master, but easy to adopt and implement. Teams should understand Scrum as a whole, but not get tied up in the weeds to over complicate things.
I try to avoid being a crazy purist on anything. Frameworks and guidelines are great, but a majority of the time in the real world things must be tailored.
However, each of these principles are important pieces of Scrum. If you aren’t following each, you probably aren’t doing Scrum.
- Empirical Process Control – This principle emphasizes the core philosophy of Scrum based on the three main ideas of transparency, inspection, and adaptation.
- Transparency – The entire team should be aware of the goals at all times
- Inspection – There will be constant review of the team’s progress
- Adaptation – Make adjustments as needed, do it. Fail fast and adapt.
- Self-organization– This principle focuses on today’s workers, who deliver significantly greater value when self-organized and this results in better team buy-in and shared ownership; and an innovative and creative environment which is more conducive for growth.
- Collaboration – This principle focuses on the three core dimensions related to collaborative work: awareness, articulation, and appropriation. It also advocates project management as a shared value-creation process with teams working and interacting together to deliver the greatest value.
- Value Based Prioritization – This principle highlights the focus of Scrum to deliver maximum business value, from beginning early in the project and continuing throughout.
- Time-boxing– This principle describes how time is considered a limiting constraint in Scrum, and used to help effectively manage project planning and execution. Time-boxed elements in Scrum include Sprints, Daily Standup Meetings, Sprint Planning Meetings, and Sprint Review Meetings.
- Iterative Development– This principle defines iterative development and emphasizes how to better manage changes and build products that satisfy customer needs. It also delineates the Product Owner’s and organization’s responsibilities related to iterative development.
The Scrum Team
Before diving into the roles on a Scrum team, it’s important to understand a couple of important traits of a Scrum team. The teams are self-organizing and cross-functional.
- Self-Organizing – This means that the team chooses the best way to accomplish their work. They aren’t directed by others outside of the team.
- Cross-Functional – The team is wholly competent enough to accomplish all the work needed without depending on anyone outside of the team.
Product owner
The Product Owner is responsible for the product itself, including the Product Backlog (more on this later). This role is one person. Not a committee or a team of people. They may consider feedback from multiple people (executives, management, CIA, etc) but they’re solely responsible for the product. Most of the responsibilities are centered around the Product Backlog, which may include:
- Prioritizing the items in the Product Backlog
- Identifying the high value items to ensure the Development Team is always producing high value performance
- Clarifying backlog items to ensure the developers have the information they need
Some of the execution may vary depending on the organization or Scrum team, but the ultimate responsibilities remain the same for the Product Owner.
There are times when the Product Owner is someone from the client’s team, and that’s ok.
Scrum Master
At a high level, the Scrum Master is a champion of Scrum, a servant leader, a coach, and a shield. Their role will vary depending on who they’re interacting with. Below are a few responsibilities of the Scrum Master based on who they’re working with:
Working with the Product Owner:
- Help ensure the Sprint goals and scope are understood by the entire Scrum team
- Assist with Backlog management as needed (for example – some Product Owners may not know the tool being used, like Jira. Guide them through the tool to manage backlogs)
- Facilitate Scrum Ceremonies/Events/Meetings as needed for the Product Owner (these are all the same thing with different names depending on who you talk to)
Working with the Development Team:
- Coach and guide the team to become self-organizing and maintain cross-functionality as much as possible
- Shield the team from external distractions and blockers
- Provide guidance for adopting Scrum and coaching members that are new to the framework
- Facilitate Scrum Ceremonies/Events/Meetings
- Ensure the team has everything they need to be as productive as possible
Working with external teams and/or the organization:
- Leading the organization to adopt Scrum
- There is likely many other Scrum Masters in on organization, so it’s rare this falls on one Scrum Master. But it’s the responsibility of all SMs in an organization to champion Scrum
- Explain why the development team must be shielded from external distraction. Things can get tricky when the Scrum Master must push back and keep the team shielded. For example – trying to keep the team member’s manager at bay so the team member can be productive. It happens. Probably more often than it should.
Development Team
This is where the magic happens. The Development Team (which are all called “Developers”) is the group of people doing the work and delivering the product. They should be empowered to self-organize and manage their own work. This not only ensures things running efficiently, but it also builds a synergy within the team to effectively work together.
There are a few important characteristics of a Development Team:
- The most important, and probably the most difficult to achieve, is being self-organizing. This means the team itself should work together to get the work done from the Backlog. Nobody should be dictating what the team does, not even the Scrum Master or Product Owner.
- Being cross-functional
- Text-book Scrum means there are no “titles” on the team. Meaning there aren’t developers, architects, QA, etc. The entire team is responsible, as a whole, to get the work done in a Sprint.
- Realistically, this rarely happens. There are usually specific roles that team members do, which is fine. However, this must come with the understanding that the team is responsible for the work as a whole.
- A success is shared by the team. Failures are as a team. Architects will do testing if needed, and so on.
- Text-book Scrum means there are no “titles” on the team. Meaning there aren’t developers, architects, QA, etc. The entire team is responsible, as a whole, to get the work done in a Sprint.
Development Team Size:
The Development teams should be small. The ideal size ranges between 3-7 people. This allows the team to be nimble and maintain the ability to adapt quickly, but ensures there is enough skill-sets on the team to accomplish the work. This number does not include the Scrum Master or Product Owner (unless they’re executing the work in a Sprint). When the team begins to grow past these numbers, there is far more coordination required and added complexity.
On large projects, there may me more than one Development team executing work from the product Backlog. Ideally, there should be multiple smaller Development Teams, and not one large Development team with 10+ people.
Scrum artifacts
Scrum artifacts are what provide the Scrum Team and stakeholders key information for understanding the product, activities being planned, and what has been completed. They allow for complete transparency and opportunities for consistent inspection and adaptation.
Product Backlog
The Product Backlog is an ordered list of everything that is known to be needed in the product.
– The Scrum Guide
That about sums up what the Product Backlog is. It’s essentially the repository for all of the User Stories that are required to build the product. One important thing to know about the Product Backlog is that it’s never “complete”. It’s a living, growing, and changing thing. Dynamic. That’s the beauty of Agile and Scrum – adapting to change as it happens.
A product will only have one Product Backlog, but there can still be multiple Scrum teams working from the same Backlog.
Product Backlog refinement (sometimes called Backlog Grooming) includes adding detail, estimate, and order to the items in the backlog. As long as there is a Product Backlog, there will be backlog refinement. Providing details for the backlog items is a collaborative effort with the Product Owner and the Scrum Team. The estimation piece (story pointing for example) is handled by the Scrum Team themselves (more on that later).
The example above is a Product Backlog a team tracks in Excel. This provides an idea of what a Product Backlog could look like.
NOTE – While using Excel to track a Product Backlog could work, most teams use a tool like Jira, Monday, Azure DevOps, etc.
Sprint Backlog
The Sprint Backlog is a collection of items pulled from the Product Backlog that are to be completed during the Sprint. The Development Team will determine all of the items necessary to meet the Sprint Goal. In a textbook Scrum world, every Sprint would contain at least one item identified in a previous Retrospective to ensure continuous improvement. This is a good practice to follow, but isn’t always feasible.
It’s important that the items that are added to the Sprint Backlog already have enough detail for the work to be completed. This includes estimating, necessary details, and a “Definition of Done” (sometimes called Acceptance Criteria). All of this is done during Product Backlog refinement. There may be times when clarification is needed on items in the middle of a Sprint. This is perfectly fine, but the goal should be to gather all the detail before the items hit a Sprint Backlog.
The Sprint Backlog belongs to the Development Team. They will identify what can be done in the Sprint to meet the goal, and they will manage the items with the Sprint Backlog. This includes managing the progress of each item to provide complete transparency to the progress of the Sprint itself.
Sprint Progress & Burndown Charts
During the Sprint the progress must be tracked. While the Sprint Backlog management is owned by the Development Team, Scrum relies on transparency. It’s important that the Sprint progress be tracked and readily available for everyone to see. One of the most common, simple, and effective ways to monitor progress is through a Burndown Chart.
What in Odin’s ravens is a Burndown Chart?
It’s a simple graphical representation of the remaining work versus the remaining time left in the Sprint. Usually the outstanding work is on the left (y-axis) and the time on the horizontal axis (x-axis). The units of work is typically displayed in the units that were estimated (story points).
- Trend Line – The chart will have a “trend line” that is used as a baseline for the Sprint (the “Estimated Effort” in the image below)
- Actual Effort – the other line on the chart will represent the actual work that has been completed as time progresses (the “Actual Effort” line in the image below)
- When the actual effort is below the trend line, things are ahead of schedule
- When the line is above the trend line, the progress is behind schedule
It’s common to see the Actual Effort line fall above the trend line at the beginning of a Sprint, then begin to drop below as work is completed and marked as “Done”.
Scrum events
Sprints
The heart of Scrum. The Sprint. It’s a time-boxed event that runs for 4 weeks or less (most commonly 2 weeks). The Development Team works towards the Sprint Goal to deliver a usable and potentially deliverable product. On the surface, this sounds simple. However, there are a few “rules” of a Sprint that are important to know and implement:
- Sprint Length
- As mentioned above, the time-box of a Sprint is 4 weeks or less. The most common is 2 weeks, but it can be tailored to the project
- When the Sprint length extends beyond 4 weeks there are a few negative impacts (below). This is why Scrum best practice is to keep it 4 weeks or less:
- Increase chances of the Sprint Goal changing
- Increased complexity
- Increased risk
- Cost predictability decreases
- Scope Changes
- Changes that could endanger the Sprint Goal should be avoided
- Scope can be clarified and re-negotiated as more is learned during the Sprint, but not at the expense of the Sprint Goal
- Quality
- Quality must remain a focus in each Sprint
- With the intense speed of a Sprint, teams can sometimes push QA to the end, making it a low priority. Avoid this
- Cancelling a Sprint
- A Sprint can be cancelled if the Sprint Goal becomes obsolete, or the company changes direction and the product is no longer needed from the Sprint.
- If a Sprint is cancelled, the work done can be reviewed by the Product Owner to determine if any of it should be released, or discarded and forgotten about forever and ever.
- Given the short duration of Sprint, cancellations are pretty rare.
Ceremonies/Meetings
What’s the difference between a meeting and a ceremony? Nothing. Absolutely nothing. Same thing, different name. So when someone calls it a Scrum Ceremony, it’s a meeting. When someone calls it a Scrum Meeting, it’s a ceremony.
With that out of the way, Lets talk about the 5 Scrum Ceremonies.
Daily Scrum/Standup
This is a 15 minute time-boxed meeting that occurs every day of the Sprint. Generally, the meeting only includes the Development Team and the Scrum Master. However, there are times when part of the Development Team is on the client side, and the Product Owner (also on the client side) will be included in the meeting. This is not ideal, but realistically can happen. If this occurs, it’s up to the Scrum Master to keep the standup meeting on track and completed in 15(ish) minutes, as well as ensure anyone outside of the Development Team does not disrupt the meeting.
The meeting structure can vary depending on how the Development Team wants to handle it, but in general there are three questions that should be asked:
- What did I do yesterday to help with the Sprint?
- What will I do today?
- Are there any blockers preventing me from completing the work and meeting the Sprint Goal?
That’s it. The standup should be simple. There are times that additional details must be discussed, but that can happen among the Development Team immediately after the standup.
The daily standup is not a detailed status meeting. Read that again. And again. A common struggle with Scrum teams is turning the standup into an hour long status meeting.
Backlog Refinement (Estimating - Story Pointing)
Product Backlog Refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. Items are reviewed and revised during Product Backlog refinement. The Scrum Team decides how and when refinement is done.
This is essentially what is involved in Backlog Refinement. It’s not always one meeting with one purpose. It’s common to have a “Backlog Grooming” session with the Scrum Team (and possibly other stakeholders) to discuss details in some of the Backlog items.
One important piece of Backlog Refinement is estimating. This is a session where the Development Team will will estimate effort for items in the Product Backlog. Most commonly, the teams will use Story Points to estimate the items (every Scrum Team I’ve worked with used Story Points). The goal is to provide a quick estimate based on the complexity of the item. The Development Team must come to a consensus on the estimation of each item. The estimations must be applied to Backlog items before Sprint Planning takes place.
Something to understand about the Backlog Refinement process is that it’s not officially included in the Scrum Framework. It can draw some criticism from Scrum purists. However, when managed appropriately, it’s an effective part of the Scrum process.
Sprint Planning
Sprint Planning is an effort by the entire Scrum Team to determine the work that will be included in the next Sprint. Officially, it’s a time-boxed event at about 2 hours for every week in the Sprint. The team can determine what works best for them as that’s just a guideline.
There are two main topic to determine during Sprint Planning:
- What work can be done during this Sprint?
- How will the work get done?
Topic #1 – What work can be done?
It’s up to the Development Team to determine how much work can be done in the Sprint. As the Development Team works together, they’ll have an idea of their “Velocity” based on how the work has been estimated, and how much they’ve completed in previous Sprints. The Velocity is the average number of work units the team has completed over the last few Sprints. It usually takes about 3 Sprints to get an accurate idea of the Velocity, so at the beginning of a project, it’s based on educated guesses and won’t be totally precise.
Determining the work included in the Sprint is solely up to the Development Team. Others on the Scrum Team can facilitate meetings or identify which items are important (though the Product Backlog should be prioritized before this point), but only the Development team will determine what will be completed.
Topic #2 – How will the work get done?
This is where the Development Team will determine how the work is going to get done. Officially this means that the team will collaborate and discuss some of the design and explain to the Product Owner how they plan on completing the work. Realistically – this usually means assigning the work to people on the Development Team to ensure everything can get done that is planned.
Once the Development Team determines what will get done, the work items will be moved from the Product Backlog to the Sprint Backlog, and off they go.
Sprint Review (Demo)
The Sprint Review is something that may greatly vary from organization to organization. The main goal of the Sprint review is to get the Scrum Team together with relevant stakeholders and review what has been done in the Sprint, and what still needs to be done from the Product Backlog. This allows everyone to be on the same page in “signing off” on what has been done and have an idea of where to focus in future Sprints.
It’s very common that the Sprint Reviews are basically a demo of what’s been completed during the Sprint. The Scrum team can gain feedback from stakeholders to ensure the product is what they need, and adapt from there. It’s common to have a demo for every Sprint, but it’s not unheard of to lump more than on Sprint into a demo.
Sprint Retrospective
The Sprint Retrospective (or Sprint Retro as the cool kids call it) is the chance for the Scrum Team to come together and inspect how things have been going for them. Taking the time to self-reflect and adapt on opportunities to improve in future Sprints. This is for anything and everything. Relationships, tools, processes, anything.
The Retro should be held after a Sprint Review/Demo, but before planning for the next Sprint. This gives the team the opportunity to implement some of the changes identified during the Retro. Keep in mind some items may be feasible to implement immediately, and some things may some additional planning. The goal is continuous improvement. The team should always aim to inspect and adapt.
Some teams, especially near the beginning of becoming a team, may wish to start a Retro with anonymous feedback. And that’s ok. There are free tools to facilitate this – such as https://funretro.io/. This allows members of the Scrum Team to add ideas to a Retro anonymously, then the team can discuss together during the Retro.
Final Thoughts
That’s Scrum in a nutshell.
Remember, this is the “real world” application of Scrum based on my years of experience. Your mileage may vary.
The official Scrum Framework has a lot more detail and a lot more “rules”. The goal here in this article isn’t to reiterate what the Scrum Guide tells us, but to quickly provide an overview to Scrum. A cliff notes of sorts.
You can find more details about the official Scrum Framework in the Scrum Guide.
What are your thoughts?
What else would you like to know about Scrum or Agile? Leave a comment below or hit me up at joey@yourpmsidekick.com.
