SCRUM in a nutshell
The “manifesto” for agile software development starts with a curious sentiment:
“Individuals and interactions over processes and tools”
It’s not that there isn’t value in the stuff on the right, continues the manifesto. It’s that the stuff on the left is even more valuable.
Scrum, agile and sprints are more than just development buzzwords — they’re ways of working and approaching complex problems that put values like communication, knowledge-sharing, embracing failure, introspection and observation front and center.
Besides the fact that working with Scrum has brought our software projects major results, there is also something very human about the methodology.
So instead of having you wade through a number of complex and jargon-heavy white papers, we thought we’d give you the TL;DR version that still answers questions like “What is Agile project management?” and “How can our team begin to use Scrum for software development?”
Scrum in Software
Agile methodology gets a lot of fancy press but there are a number of other similar methodologies, including:
- eXtreme Programming
- Crystal Clear
- Agile Unified Process
Scrum’s rise to the top, however, is because of its simplicity, straightforwardness and the ease with which teams, across functions, can implement and collaborate. Often, team members experience perks like:
- Feedback gathered from stakeholders, customers and end users throughout the process of development
- Rapid and aligned reactions to changing requirements
- The dev team’s increased velocity, thanks to 1-4 week sprints, which provide a sense of urgency and focus
- Shippable increments delivered early and often, enabling stakeholders to provide real-time feedback (and team members to observe customers in action)
- Productive, effective, and efficient meetings to help ensure that developers get help when they need it
Scrum is not a process, technique, or definitive method.
It is a framework that offers freedom of implementation.
Through organized yet creative “sprints”, Development Teams bring a design thinking and problem-solving mindset to software. User experience is not in the rearview but right in front of you so the team can bring real customer value, which translates to real business value.
Scrum’s power and potential, then, is all in adopting a user-centered development mindset. This is what can help web development companies create and deliver complex but successful products users can actually benefit from.
The basic framework consists of Scrum Teams and their associated roles, events, artifacts, and rules, detailed by Ken Schwaber and Jeff Sutherland, who developed Scrum.
Yet, there are now quite a few successful “Scrum”mers (like Kai Haley, leader of the design sprint training program at Google) and “Sprint”ers (like Jake Knapp, design partner at Google Ventures) who have perfected the art of running a successful Sprint and the formation and facilitation of a Scrum Team to a tee.
To get started, you’ll need to have an understanding of its structure and working style.
The Scrum Team
The Scrum Team is made of a couple of concrete roles, which we’ll look at here. Teams are self-organizing and cross-functional.
The Product Owner: responsible for maximizing the value of the product resulting from the work of the Development Team.
The Development Team:team members who work on delivering a potentially releasable Increment of the “Done” product at the end of each Sprint. Development Teams are structured and empowered by the organization to organize and manage their own work.
The SCRUM Master: responsible for promoting and supporting while also connecting with those outside the Scrum Team, helping them to understand which of their interactions with the Scrum Team are helpful and which aren’t.
Pre-determined Scrum “events” are a great way to create regularity and minimize the need for meetings. Events have a set time duration they can’t go beyond.
The heart of Scrum is a Sprint, which usually runs anywhere from 1-4 weeks. The goal is a useable, and potentially releasable product Increment. Sprints have consistent durations throughout a development effort. Don’t be surprised if you’re facing 8-hour days of consistent focus.
Another principle is that a new Sprint starts immediately after the previous one wraps up.
Sprints consist of the following activities:
- Sprint Planning
- Daily Scrums
- the development work
- the Sprint Review
- the Sprint Retrospective
While no changes are made that might take the “Sprint Goal” off-course, the scope can be clarified and re-negotiated with the Product Owner and Development Team as more is learned.
There’s no need for your team to do much homework prior to the Sprint. But, the designated Sprint Planning stage is where the team creates a plan for the collaborative work to come. It’s also considered an event so, naturally, it has a time limit: a maximum of eight hours for a one-month Sprint.
Every day of the Sprint, there is a 15-minute event called the “Daily Scrum”. There is where the Development Team plans work for the next 24 hours and inspects the work done yesterday. The Daily Scrum is held at the same time and place each day to reduce complexity.
Sprint Review and Retrospective
A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. It is informal and lasts, at most, for four hours.
The Retrospective is a chance for the Scrum Team to inspect itself and create a plan for improvements for the next Sprint. The atmosphere is open to feedback and sharing because presentation of the Increment is all about getting feedback and fostering collaboration.
So Scrum Teams engage in Scrum Events. And Scrum Events inevitably result in Scrum Artifacts. Think of these as the “residue” of activities and events that also give the team opportunities for inspection and adaptation.
- Product Backlog:an ordered list of everything that is known to be needed in the product. Any requirements for any changes to the product go here. It’s the domain of the Product Owner to advise on/tend to content, availability, and ordering.
- Sprint Backlog: from the list of “Product Backlog”, the “Sprint Backlog” items are those that are selected for the Sprint; this includes a plan for delivering the product Increment and realizing the Sprint Goal.
While some software teams decide to cleave design and development into two separate sprints, others favor an integrated sprint approach that brings together UX designers, developers and testers working together as a scrum team.
The benefit to this integrated environment, especially using Scrum, is that it allows you to constantly maintain a UX mindset and focus. You’re actively testing the product in iterations as you go along, allowing the next increment to thoughtfully reflect improvements from the previous version.
Of course, this calls for a well-functioning development team in order to build a powerful and ingenious product.
However, Scrum comes with a caveat: using it is not a guarantee that you’ll end up with a successful product.
Agile development companies must embrace the idea and reality of “failure” and ask themselves what this term means to them.
The other consideration is the role of a UX designer within an integrated Scrum team. It’s the UX designer who keeps a finger on the pulse of the project’s alignment with the customer, constantly bringing a clear understanding of product vision and its requirements.
This UX focus, then, directly translates into a superior customer experience.
So, at its core, Scrum ultimately provides a better CX for clients and internal teams. Customers are integral to the framework and need to be deeply involved in the development process.
It’s the interactions with the customer and their observed experience that help to guide each successive iteration stages. It’s direct involvement coupled with ongoing, incremental working that makes the Scrum framework so powerful in software development.
Download your free guide for development process in UX driven projects