Back to Basics: What is Scrum for Agile?
by Todd Cotton, on Feb 24, 2020 4:08:48 PM
But to “be agile,” teams must learn to uphold a system of values and principles:
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
With that said, scrum is one of a host of effective tools for teams that believe in agile principles and want to continuously deliver business value.
What is scrum?
Scrum is an iterative process that helps a team collaborate and coordinate the delivery of working products early and often.
Commonly used in information technology and software development, it’s an agile process model designed for small teams working interdependently. Ideally, the team focuses on its own tasks. It’s capable of self-management and decision-making.
The scrum model consists of set roles, artifacts and ceremonies.
The three roles on a scrum team.
Scrum teams include three equally important roles: the product owner, scrum master and development team.
1. Product Owner
The product owner is the scrum team’s connection to the rest of the business, and therefore understands how the team can best deliver value. In many cases the product owner comes from the line of business, knows the product, and may be a former product manager.
The product owner has a vision for the product; how it should grow, change, evolve and adapt.
Also, by maintaining regular communication with stakeholders, clients, subject matter experts (SMEs) and others, the product owner enables the team to flex and adapt to work that delivers the most value for the business.
- Create and prioritize the product backlog.
- Select which story cards from the product backlog are added to the sprint backlog and decide which cards are implemented.
Traits of an effective product owner:
- Effective at relationship building.
- Strategic and a visionary.
- Great communicator.
2. Scrum Master
Scrum must be a consistent, iterative framework. The person charged with protecting the scrum process is the scrum master.
The scrum master is the scrum coach, also embedded in the team. He or she may be a “player-coach” in some teams, working on stories while also helping the team function.
- Facilitate the scrum ceremonies.
- Develop each team member to master their strengths and responsibilities.
- Instill and grow the team’s knowledge of and effectiveness with agile and scrum.
- Be the guardian of the agile mindset, and the agile process.
Traits of an effective scrum master:
- Great facilitator.
- Expert in agile.
- Servant leader.
3. Development Team
The third, crucial part of the scrum team is the development team. It includes those who will do the work to complete the stories and deliver value. The team may include specialists and generalists of many different disciplines and strengths.
In a technology or software team, the development team may include:
- Business analysts
- Data scientists
- Quality assurance
- Maintain the agile and scrum process.
- Work efficiently on prioritized work.
- Collaborate and be willing to learn skills outside a given discipline.
- Maintain focus on key stories, and work exclusively on work within the team.
Traits of an effective development team member:
- Highly skilled in his or her given discipline.
- Willing to be “t-shaped,” working on what best serves the team at the time.
- Good communicator.
- Willing to ask questions.
Though each teammate is an expert in a certain discipline, everyone is willing to do whatever it takes to achieve the team’s goals, get work done and deliver business value. Developers may need to learn to do some testing, and a QA tester may need to do some design work. This doesn’t require mastery, but means each player is capable of supporting on basic tasks across the team.
An artifact is a document the team creates that instructs or inspires the process in some way. There are several types of scrum artifacts. The most common are explained below.
The working agreement is the first artifact the team creates. It outlines how the team will operate and work together.
Aspects of the working agreement may be basic, such as:
- We will be prompt, starting our ceremonies (or meetings) on time.
- We will respect time boxes and end meetings on time.
- Each working session, meeting or ceremony will have an agenda.
- We will be open to any and all ideas.
Other inclusions may be unique or specific to the team, potentially including:
- We will not play loud music in the working area.
- We will not have peanuts in the working area.
- We will not eat smelly foods, like fish, in the working area.
The most important part of the working agreement is that it’s created collaboratively by the team. Each team member should feel ownership of the rules and willingly help hold each other accountable.
Definition of Ready
Also defined by the team, this is the list of requirements needed in order to begin work on a story.
Perhaps the “definition of ready” requires that a story have a title, basic requirements, size, and acceptance criteria. To take it a step further, it may say the story must follow the INVEST rule for user stories.
Definition of Done
For use after a story has been worked on, the “definition of done” lists what’s required for a story to be considered complete.
It is highly dependent on the team and the organization. For example, for a software development team, an organization may have several environments: development, testing or QA, and production.
Example definitions of done:
- The story has gone through the certification environment and is in production.
- The story has been installed in the certification environment.
- The story’s integration testing is complete.
- The story must meet acceptance criteria.
In Scrum, the “definition of done” must be met before demonstrating the feature to stakeholders.
Scrum Board or Storyboard
Scrum teams should have a board that shows what the team is currently working on. It may be called a Scrum board, story board, Kanban board or a host of other names, but regardless of the name the goal is the same.
The scrum board shows progress as user stories are moved from column to column across the board.
Each user story is written on an index card or Post-It. You’ll often see the same number of stories in the development stage as there are developers (one story per developer). The same goes for testing.
Boards may be digitized in a tool like Jira or Rally, but be aware of how the constraints of digital tools dictate the flow of work. Physical boards are endlessly configureable and give the team total control over the board’s design, which is why we prefer physical boards. For distributed teams, a physical board may not be feasible.
The sprint backlog is a prioritized list of the most important user stories the team should work on next. It contains the user stories or work items to be completed during the current and next sprint.
After the development team completes a user story, they pull in the highest priority story from the sprint backlog and move it to the scrum board.
Created and prioritized by the product owner, the roadmap is the long-term plan for stories coming down the pipeline.
While valuable for the team, it also displays what the team is working on beyond the immediate sprint for anyone in the organization to see.
Epics, which are essentially large “projects” (as they’re known in the waterfall world), are broken into features and stories. The epics are prioritized on the roadmap, then each epic is broken down into individual stories that are also ordered.
Ceremonies are the regularly occurring events that build collaboration among the team, keep everyone on the same page, and hold them accountable.
Sprint ceremonies may include:
- Backlog refinement. At the beginning of each sprint, the team refines the backlog of stories, which is the work the team expects to complete during the next sprint or two.
- Sprint planning. After refinement, sprint planning enables the team to discuss each story and determine if they have enough information to execute the work during the sprint. At this point, the team ensures it meets the definition of ready.
- Daily standup or daily scrum. Each morning, the team gets together for a quick meeting, asking each team member three questions:
- What did you do yesterday?
- What are you doing today?
- Do you have any blockers or issues?
- Sprint review and demo (i.e. show and tell). At the end of the sprint, if a story meets the definition of done, it is presented to stakeholders. The goal is to move work to production and deliver business value each sprint.
- Retrospective. Following the review, the team convenes to discuss the previous sprint. Consider two key questions:
- What went well that we need to keep doing?
- What didn’t go so well and needs to change?
Here is an example calendar showing the cadence of a sprint’s ceremonies:
See how scrum relates to agile.
Scrum is an effective framework for managing work for many types of teams. Often the hardest part is getting started.
If you’re new to agile, or want to see how scrum and other agile processes fit into the agile methodology, view the Agile Discussion Guide. Now in its fourth edition, this guide is designed to help change agents and leaders start the agile conversation in their organizations.