As you work towards creating your web or mobile app, pretty early on you'll probably hear developers mention Agile software development and the Scrum framework. In this post, we'll demystify these terms and walk you through a typical cycle in Scrum.
tl;dr: Scrum is a lightweight Agile framework that functions in short, iterative cycles (e.g., two weeks), at the end of which the development team delivers working software and receives feedback from stakeholders. The different meetings and artifacts built into Scrum allow the team to remain organized and transparent while continually adapting to stakeholder feedback.
What are Agile and Scrum?
Agile is an approach to developing software that stresses the importance of collaborating with the customer, adapting to changing requirements, continuously delivering value, and working on a self-organizing team that is always seeking to improve its efficiency. It draws on some of the principles that have guided Toyota's manufacturing processes since the 1950's, such as sustainable work and avoiding the waste of resources. These ideas started to be adapted to software development in the 1990's, and they were consolidated in the Manifesto for Agile Software Development in 2001 by 17 software developers looking to improve contemporary practices.
Scrum is an Agile framework that enables development teams to organize themselves and their work. It provides practical ways to apply Agile principles to day-to-day work. In Scrum, work is completed in short and iterative cycles called sprints, and progress is measured by managing a product backlog – but we'll go deeper into these concepts shortly. Scrum is all about clear communication and transparency, inspecting the team's work to look for ways to improve, and adapting processes to optimize the use of time and resources.
So what exactly is a "sprint"?
A sprint is the time box that encloses increments of work in Scrum. It's a predetermined, regular period of time ranging from one week to one month. At sophilabs, we usually work in two-week sprints. At the end of a sprint, the development team delivers usable software. Stakeholders then give the team feedback, and the team figures out how they can improve during the next sprint.
What are Scrum "artifacts"?
In Scrum, artifacts are the documents that help the development team keep track of their work and stay transparent with the client and with each other. Each artifact serves a unique purpose.
Simply put, the product backlog is a descriptive list of all the elements the product will need. Each product requirement usually takes the form of a user story, which briefly describes a specific feature and the goal this feature would help the user achieve. A user story often takes the following format: As a [type of user], I want [a feature or functionality], so that I can [achieve my goal].
User stories keep user needs and business value front and center throughout the development process. They can include acceptance criteria, which are the specific attributes that detail how to fulfill the functionality and are often unique to the given feature.
In the product backlog, user stories are prioritized according to the product stakeholders' needs. The stories at the top of the list should also be the most specific and refined stories so that the development team is clear on what the stories involve and can easily add them to the next sprint.
The sprint backlog is the list of user stories that the team will complete on a given sprint. It's a subset of the product backlog, usually taken from the very top.
The Scrum board tracks the tasks the team is working on during the current sprint. Each task must be placed under one of at least three columns; usually these categories include To Do, In Progress, and Done. The Scrum board helps team members stay accountable and allows for transparency on the team's progress throughout the sprint.
Team members use the Definition of Done (DOD) to determine when each feature or user story is complete. The DOD is an agreement between the Scrum team and stakeholders on the quality and working elements every feature must have in order to be considered done and potentially be released.
A burn-down or burn-up chart demonstrates how much the team has accomplished over a period of time. Time is shown on the horizontal x-axis, and the scope of the project is represented on the vertical y-axis.
Who makes up a Scrum team?
In Scrum, there are three defined roles within a development team. Let's take a look at what these are.
The Product Owner is in charge of maximizing the value that the product being created delivers to its stakeholders. The Product Owner achieves this goal by making sure that all the product needs the product stakeholders have described are properly documented and organized in the product backlog.
The Product Owner can be someone from the client side (i.e. a startup founder or a tech executive) or someone from the software provider side (at sophilabs, our Product Managers can take on this role). It really depends on how involved an entrepreneur wants to be in the software development process.
The Scrum Master is responsible for guiding the team through the Scrum process, coaching them through any challenges and providing support when team members encounter obstacles. They're the team's Scrum and Agile expert.
Team members are the software designers and developers who design and build the product. They're responsible for communicating openly, collaborating on solving problems, and working together to improve the team's efficiency.
How does a sprint work?
Now that we understand how the Scrum team is structured and what materials are used to organize work and track progress, it's time to see what Scrum looks like in action. For that we'll need to break down the Scrum ceremonies that happen throughout the sprint. Ceremony is the term Scrum uses for the different events and meetings that take place in this framework. There are four types of ceremonies that occur every sprint.
The team holds this meeting at the beginning of each sprint. The purpose of sprint planning is to determine the most valuable thing that could be built for the product next and to define an actionable goal that the team can commit to fulfilling by the end of the sprint. In order to do so, the team picks user stories from the Product Backlog that are aligned with this goal and that make sense for the sprint. Finally, they define a tactical plan on how this work will be done.
Sometimes also called a standup, the daily Scrum is a brief meeting (no more than 15 minutes) that the team conducts every day. Each team member shares with the team the work they've completed or challenges they've faced since the last daily Scrum. The team also uses this opportunity to start brainstorming solutions to any obstacles team members might be facing. The daily Scrum keeps team members on the same page as far as the progress they're making towards reaching the sprint goal and which issues they need to address.
The sprint review happens at the end of every sprint. It's a meeting in which the Scrum team shows stakeholders the progress they've made by demonstrating the working software they built during that sprint. Stakeholders then give the team feedback (usually documented as new user stories or tasks on the Product Backlog), allowing the team to continue improving the product according to stakeholder needs.
This meeting happens after the sprint review and before the next sprint planning session. During the sprint retrospective or the retro, the development team (usually without the presence of stakeholders) examines the way they worked together over the last sprint. Team members share what they think went well and what could go better. The purpose of the retro is for the team to identify areas to improve and reach a consensus on how to improve them. It's one of the ways Scrum supports incremental change and encourages continuous improvement.
Scrum is a lightweight framework that helps teams stay organized and Agile. At sophilabs, we love the way Scrum facilitates constant communication within the team and regular feedback from stakeholders.
We hope our quick introduction to Scrum helped you get a handle on the basics! 1 If you need a quick refresher or would like to learn more Agile terms and concepts, check out our handy Agile Development Glossary.
We’d love to work with you.
We treat client projects as if they were our own, understanding the underlying needs and astonishing users with the end results.
Why Building an MVP for Your App Idea
Building a MVP provides an alternative path to product development that allows you to avoid common risks. It is not a prototype, but a totally usable product trimmed down to the bare essentials.
Product Inception: Defining the Who, What, Why, and How of a Digital Product
We explain what Product Inception is and why it's an essential part of creating a successful software product. We’ll then break down the different phases of Product Inception.