Author
The Scrum framework is the most popular approach to the broader Agile methodology that has dominated software development for the past two decades. While the highly fractured nature of the market makes reliable statistics hard to come by, a large majority of software development teams use a project management approach described as some form of ‘Agile’.
The most recent, 15th, State of Agile report found 94% of the companies the 1382 international respondents worked for had adopted Agile. Of the majority who did follow a variation of the Agile methodology at team level, 66% said they did so through a Scrum framework.
That makes Agile with Scrum, by some distance, the most followed approach to software development in 2021. The significance of the Scrum framework to contemporary software development is brought into even sharper focus by the fact an additional 15% of respondents followed other close derivations of Scrum.
9% said their team follows ScrumBan, a hybrid framework that combines elements of Scrum and Kanban. And a further 6% Scrum/XP, combining elements of Scrum and Extreme Programming (XP).
If you could only choose one approach to the software development process and project management to gain an understanding of, it would be the Scrum framework. Which makes Scrum a great place to start exploring the theory of Agile software development and the more specific processes and steps introduced by the various frameworks that fall under the Agile methodologies umbrella.
Can We Help You With Your Next Agile Software Development Project?
Flexible models to fit your needs!
How does the Scrum framework fit within the Agile methodology?
In short, the difference between a methodology and a framework is their degree of abstraction from the actual activity their role is to optimally plan and manage – software development.
We could go down the rabbit hole of exploring and debating the distinction between a methodology and a framework. And if Agile is really, technically, a methodology, or Scrum a framework. I’ll leave that for academics and people who need to sell books.
The Agile Alliance defines the Agile approach to software development as:
“…an umbrella term for a set of frameworks and practices based on the values and principles expressed in the Manifesto for Agile Software Development and the 12 Principles behind it.”
And that’s the broadly accepted definition within the software development community. Agile software development, across implementation frameworks, also has four fundamental characteristics:
The team
Agile focuses on the software development team as an autonomous entity whose goal is the output of a high performing software system.
Iterative development
Software systems are constantly improved based on user data and feedback rather than released once as ‘finished products’ whose success relies on an absence of mistaken assumptions during a one-time planning and analysis phase at the start of the process.
Incremental development
Each successive version of a software system starting with a publicly or beta-tested MVP is usable, and each builds upon the previous version by adding user-visible functionality.
Version control
The practise of tracking and managing changes to software code. Version control software tools are used to track every change to the code in a special kind of database. If a mistake is made, developers can regress the database to compare earlier versions of the code to help fix the mistake while minimising disruption to the rest of the team’s work.
Scrum, meanwhile, under the umbrella of the methodology’s 4 values, 12 principles and 4 fundamentals, tells an Agile software development team:
- what is implemented;
- in which order;
- by whom;
- and, how.
Scrum is flexible and actively avoids being highly prescriptive but is a degree of abstraction closer to the practical execution of building a software application. It defines things within the software development process including team roles, phases of the development life cycle, that development cycles are organised into incremental ‘sprints’ and a handful of defined practices such as daily stand-up meetings.
A brief history of the Scrum framework
The Scrum framework was first formalised by Ken Schwaber’s 1995 paper The Scrum Development Process and made its public debut at the Object-Oriented Programming, Systems, Languages & Applications (OOPSLA) Conference ‘95 in Austin, Texas where it was co-presented by the author Jeff Sutherland.
Sutherland, along with colleagues Jeff McKenna and John Scumniotales, had already implemented a Scrum framework for software development teams at the Easel Corporation, a successful software development company acquired by VMARK in the mid-1990s.
The Scrum Master details how the three Easel Corp. colleagues were inspired by the well-known 1986 article The New New Product Development Game, written by Hirotaka Takeuchi and Ikujiru Nonaka and published in the Harvard Business Review. The classic article outlined a new holistic approach to innovation that it compared to the sport of rugby, where the whole team “tries to go to the distance as a unit, passing the ball back and forth”.
The name Scrum comes from the passage of play in rugby that sees the whole team combine their collective strength in an attempt to gain ground.
Photo credits: Quino AI
So Scrum actually pre-dates the Agile Manifesto by six years. The Agile Manifesto, which has become the software development industry’s 21st century equivalent to Moses’s Ten Commandments, was published in 2001 after Sutherland and Schwaber came together with another fifteen colleagues for a working retreat in Snowbird, Utah.
In the 25 years since Schwaber’s paper on Scrum was present in Texas, and 20 since the creation of the Agile Manifesto, Schwaber and Sutherland have successfully evangelised the framework as the dominant way to create software through high performing teams.
Mike Cohn’s evolution of Scrum through the use of user stories as a tool to describe client-focused work goals and story points as a metric of team velocity and quality of work, was introduced in 2012 and has since had a major impact on how the framework is implemented.
A Scrum team consists of 3 defined roles
There are only three team roles defined by the Scrum framework:
- Product Owner
- Scrum Master
- Development Team
Product Owner
The Product Owner (PO), always one person, is the ambassador, or champion, of the eventual software product. It is the role with the greatest authority within the Scrum team and framework and bears ultimate responsibility for the quality of the software produced.
The PO also represents the internal or external customer the software is being sponsored by or created for as well as other stakeholders such as the end user. That means a good Product Owner will have a deep understanding of business, customer and market requirements.
That will allow them to effectively build and manage the product backlog, organising it into Sprints. If anyone else in the team wants to make changes to the product backlog, features or order of priority, the PO is the person to convince.
Depending on the organisation and project, a Product Owner can also be part of the development team executing on the product backlog, for example, a senior developer. But they are also often on the PO of the project and delegate the product backlog to the development team.
The Product Owner is also responsible for deciding on the point at which the product represents an MVP ready to be shipped as a first working iteration.
Scrum Master
The Scrum Master is a moderator and facilitator rather than a traditional project manager, whose leadership role and responsibilities are split between the Product Owner, Scrum Master and Development Team.
The role of Scrum Master is to maintain the team’s focus, motivation and to remove any bottlenecks or blockers impeding their work. For example, if a member of the Development Team keeps getting called away to help on another project, the Scrum Master would be expected to step in and mediate a resolution.
The Scrum Master is also responsible for the implementation of the Scrum framework and Agile philosophy, helping to coach the Product Owner, Development Team, project sponsor on the Scrum process and make sure it is being implemented well. If a meeting room with a projector is required for a sprint review session, the Scrum Master is responsible for making sure one is available, or any other logistical needs.
Development Team
Scrum development teams are a tight-knit group of usually not more than seven members. Traditionally, the Scrum framework prefers members of a development team to be physically located together. That can often be impractical in the new era of increasingly remote work and new distributed-Scrum practises are now quickly evolving.
The members of the development team will have various skillsets which combine to provide the expertise needed to build the software system whose output is the goal. There will be front end developers, back end developers and now often DevOps engineers, with experience in the coding languages, frameworks, tools and technologies the product will be built on.
The team should be balanced to the needs of the project and its optimal efficiency. For example, if the software system has a relatively simple front end but complex back end, the development team should have more back end than front end developers. If the balance isn’t right, uneven progress of different elements with dependencies becomes a blocker to efficient progress.
A good Scrum development team will self-organise and approach their projects with an “all for one and one for all” attitude, helping one another towards successful individual and combined outcomes.
When does IT Outsourcing work?
(And when doesn’t it?)
Scrum team size – how big can the team be?
A Scrum team was historically relatively small and comprised of 5-9 individuals (including the Scrum Master and Product Owner if these are independent roles). More than that was considered problematic in the context of the Agile priority of combining autonomy and freedom with high-performance and quality output. However, in recent years Scrum team size has become more flexible.
Larger Agile software development projects that necessitate more people working on them than considered optimal for a single team but would still like to implement the Scrum framework can use a scaled Scrum approach like Large-Scale-Scrum (LeSS) or Scrum-of-Scrums. These approaches see the work split between multiple semi-autonomous but coordinated Scrum teams.
The Scrum process for Agile software development
The Scrum frameworks process is, like all Agile approaches to software development, both iterative and incremental. That means development tasks towards a working first iteration of the product are divided into iterations called Sprints in Scrum.
Sprints typically represent 2-3 week cycles of work and represent a timebox within which a set of features, called Epics and User Stories – or just Stories, are developed. If enough features for a shippable MVP cannot be completed in a single Sprint, it becomes an incremental phase with subsequent Sprints combining towards an iteration, or ‘release’ in Scrum-speak.
In contrast to the Waterfall software development methodology, the standard pre-Agile approach, Scrum breaks a strictly sequential development life cycle into smaller cycles. Each cycle is followed by a review of the released software by the development team, end user and other stakeholders including the software owner which informs subsequent cycles.
That means changes can be made to the requirements and features list (and its order of priority), which is not possible in Waterfall where all the planning is completed and fixed in the initial development stage and a ‘finished’ product released at completion. The Scrum framework’s Agility helps ensure the end product best meets the requirements of the customer or user.
Scrum ceremonies and events
Scrum is a framework because it both leaves plenty of space for the Scrum Team to autonomously make their own decisions and adjust processes to the needs of the project and insists on a structure that freedom and interpretation must take place within. Scrum’s framework consists of several prescribed events and a small number of hard and fast rules.
The central rule of Scrum is that events are ‘time boxed’ – assigned a fixed duration that cannot be adjusted after they begin. For example, once a Sprint assigned a two-week duration has started it cannot subsequently be reduced to eight working days or increased to twelve.
The prescribed Scrum events and ceremonies are:
Sprint Planning
Sprint Planning is a collaborative event including the entire Scrum Team and concludes with a decision on the features, or Stories, to be completed within the Sprint. The Product Owner should lead a discussion that prioritises the items in the Product Backlog and their contribution towards the Product Goal.
External individuals that are not part of the Scrum Team can be invited to participate in Sprint Planning if team members want their advice and input. Sprint Planning must answer the following questions:
- Why is this Sprint valuable?
- What items of the Product Backlog can be completed in this Sprint?
- How will the work get done?
Sprint
Sprints sit at the core of the Scrum Agile software development process and are where the actual work gets done. They are time-boxed and should be under a month and preferably 2-3 weeks to maintain the focus needed for a consistently efficient rate of progress towards the Product Goal.
Scrum.org insists:
“When a Sprint’s horizon is too long the Sprint Goal may become invalid, complexity may rise, and risk may increase.”
Sprints follow the rules:
- No changes are made that would endanger the Sprint Goal;
- Quality does not decrease;
- The Product Backlog is refined as needed; and,
- Scope may be clarified and renegotiated with the Product Owner as more is learned.
Daily Scrum
Its regularity makes the Daily Scrum the most familiar event of the Scrum process and is an event described as “by the development team for the development team”. The Product Owner and Scrum Master only participate in the Daily Scrum if they hold dual roles and are also part of the development team and working on items in the Product Backlog.
A time-boxed 15-minute morning meeting that takes place, without fail, every working day at the same time and, if at all possible, in the same place. It is designed as an event that keeps the focus on progress towards the Sprint Goal in a way that promotes self-organisation and accountability of individual developers to each other and the Development Team as a whole.
The Daily Scrum tracks progress towards the Sprint goal, synchronises activities and outputs a plan for the next 24 hours. The Scrum Master, even if not directly participating as a developer, is responsible that the Daily Scrum happens consistently and effectively within the allotted 15 minutes.
It’s important to Scrum to clearly differentiate the Daily Scrum from a traditional ‘status meeting’, where team members provide an update on their progress for the tasks they’ve been working on to somebody else who is maintaining a plan, like a project manager. A Daily Scrum, by contrast, is designed to facilitate the self-organisation at the heart of the Agile philosophy.
The Development Team has the freedom to decide on the structure of the Daily Scrum with the only hard and fast rule that it is focused on progress towards the Sprint Goal and results in an actionable plan for the day’s work ahead. The Daily Scrum should keep team communication tight and transparent, identify any blockers to progress so they can be dealt with, and mean no further meetings are necessary.
A Daily Scrum can often simply consist of each member of the Development Team asking and answering three questions:
- What did you do yesterday?
- What will you do today?
- Are there any impediments in your way?
The Scrum Master is responsible for dealing with any impediments to progress.
While the Daily Scrum is designed to eliminate the need for any further meetings throughout the day that doesn’t mean there shouldn’t be detailed discussions between team members throughout the day and there usually is.
The Daily Scrum is also often referred to as ‘Daily Stand-Up’ as the original Scrum framework prescribed that attendees remain standing as doing so adds a degree of discomfort that helps keep everyone alert and to the 15-minute deadline.
Sprint Review
The Sprint Review is all about celebrating the team and demonstrating what their work has accomplished. The Scrum Team presents the results of their work to each other as well as any external stakeholders the Product Owner feels it is appropriate to involve.
Scrum Team members and other key stakeholders review what has been achieved during the Sprint and discuss any changes to the environment that might require the Product Backlog to be updated. What Product Backlog items can be considered ‘done’ and ‘not done’ according to the Team’s definition of these terms is also usually decided.
Based on the information presented and discussed at the Scrum Review, attendees collaborate on what should be done next.
The Sprint Review is the penultimate event of a Scrum development cycle and is time-boxed to a maximum duration of 4 hours, in the case of a 1-month Sprint, but is usually shorter. The end result of the Review should be an updated Product Backlog and a provisional list of the items to be tackled during the next Sprint.
Sprint Retrospective
The final event of a Sprint and Scrum development cycle, the Sprint Retrospective is about analysing what could be done better in the next Sprint to improve the efficiency of work and quality of output. That’s achieved by examining the variables of the previous Sprint like team members, communication, tools, processes and the Team’s Definition of Done.
The Team should commit to implementing in the next Sprint anything it feels could be improved for greater effectiveness. The Sprint Retrospective is time-boxed to a maximum of 3 hours for a 1-month Sprint and is usually shorter.
Scrum artifacts
The ‘artifacts’ of Agile Scrum software development are, like the original Latin definition of the word, something created – either a tool or an inspiration. The three main Scrum artifacts are:
- Product Backlog
- Sprint Backlog
- Increment
Product Backlog
The Product Backlog is an evolving list, with items in order of priority, of all the tasks that need to be completed to improve the software product. It acts as the single source of work executed by the Scrum Team, whose members should never be working on anything that is not a Product Item backlog. The items in the Product Backlog should all make a meaningful contribution to achieving the Product Goal.
The items in the Product Backlog and their order of priority can be agilely updated by the Scrum Team throughout the process. But each new Sprint will tackle items provisionally assigned the highest priority during the previous Sprint Review and confirmed during the Sprint Planning.
Sprint Backlog
The Sprint Backlog consists of the highest priority items from the Product Backlog chosen for completion during the current Sprint. The items in the Sprint Backlog should correspond to the Sprint Goal, answering ‘why?’ they are there and be underpinned by an actionable plan of how they will be delivered.
The Sprint Backlog is a plan created by and for the Development Team and is a visible, real-time picture of work completed, in progress and planned for completion during the current Sprint in the pursuit of its Goal. It’s updated as the Sprint unfolds and more is learned and progress is tracked at the Daily Scrum events.
Increment
A Scrum increment must represent a concrete step towards the Product Goal and must consist of usable new Stories that work together with existing increments to improve the software product.
A Sprint may include more than one increment but cannot conclude without the release of an increment. All increments that meet the Scrum Team’s formal description of their definition of done are presented at the Sprint Review. If a Sprint contains multiple increments, those completed earlier in the Sprint can and should be released if they are ready to add value to the shipped software.
In Conclusion
You should now have a good theoretical overview of Agile software development with Scrum and an understanding of why it is considered to be one of the most effective contemporary frameworks for high performing software development teams.
K&C flexibly provides experienced Scrum Teams, and Agile Scrum team augmentation to fill in gaps, tailored to the needs of our partners’ software development projects. If you would like to discuss details with us or receive a preliminary quote for your next project please get in touch!
K&C - Creating Beautiful Technology Solutions For 20+ Years . Can We Be Your Competitive Edge?
Drop us a line to discuss your needs or next project
