Scrum for developers in 10 minutes
Scrum is a popular framework for managing software projects. It's used by lots of big companies including FAANG, but its also popular among smaller companies and startups.
A lot of developers have heard of Scrum, but don't really know what it is or how it works. This post is intended to give you a quick overview and how it might be implemented in your team.
What is Scrum?
Scrum is one of the more popular Agile frameworks, it's designed to help small teams deliver software continuously and iteratively.
It's not a methodology, it's a framework - Scrum is intended to be a set of guidelines that can be adapted to suit your team rather than a bunch of explicit rules.
Scrum is based on a few core principles:
Transparency
Ensuring everyone involved in the project is aware of what's going on and can see the progress being made.
Inspection
Regularly reviewing the project to ensure it's on track, the team is working effectively, and the process is working.
Adaptation
Making changes to the project or Scrum processes as needed.
The Sprint
Sprints are fixed periods of time when the team works on an agreed-upon set of tasks to achieve a sprint goal.
During a sprint, no changes are made that might endanger the sprint goal. By the end of the sprint, the team should have a potentially releasable product increment.
A scrum team is always in a sprint, a new one starts immediately after the previous one ends.
A sprint should be no longer than a month, commonly it lasts 2 weeks
Scrum Elements
These 3 scrum elements (or artifacts) are core parts of scrum:
Product Backlog
The product backlog is a prioritised list of features, improvements, and bug fixes that the team will work on.
It's the single source of requirements for any changes to be made to the product.
Sprint Backlog
The sprint backlog is a subset of the product backlog, and contains the tasks that the team has agreed to complete during the sprint.
You'll create the sprint backlog during the sprint planning meeting.
Increment
The increment is the sum of all the work completed during the sprint, it's basically the new version of the product.
The increment should be to a releasable standard at the end of the sprint, but it doesn't have to be released publicly.
This means all work completed during the sprint should be tested, reviewed, and ready to be deployed in order for it to be "done".
Done
Each scrum team should create their own definition of "done", once a task is done it can be considered complete and ready to be deployed.
If a task isn't done then it isn't considered complete and should return to the product backlog at the end of a sprint.
Developers must ensure their work conforms to the teams definition of done before they move on to the next task.
A good definition of done may include:
- Code meets the acceptance criteria laid out in the task
- Code is tested and all tests pass
- Code has been reviewed by another developer
- Code has been deployed to a staging environment
Scrum Roles
A scrum team is made up of three roles
Product Owner
The Product Owner is the "voice" of the customer, they're responsible for maximising the value of the product being built by the team.
Their responsibilities include:
- Prioritising the product backlog of work
- Defining new features and requirements
- Working with the developers to clarify requirements, and ensure the backlog of work is understood
The Product Owner should be a single person, not a group of people or a committee.
Any feature requests (e.g. from the CEO, Marketing, or Sales teams) MUST go through the Product Owner.
Scrum Master
The Scrum Master is responsible for the team's effectiveness. They ensure the scrum framework is followed and remove anything that might impede the team's progress.
They help to facilitate decision-making within the team but don't make any product or technical decisions.
Their responsibilities include:
- Facilitating Scrum meetings
- Coaching the team in Scrum practices and help them to continuously improve
The Scrum Master will manage the process, but does NOT manage the development team.
Some companies will have a dedicated Scrum Master who works across multiple teams, otherwise the role can be played by a tech lead.
Where the Scrum Master is also the team's technical lead, they may have some line management responsibilities & be involved in technical decision-making as part of their regular role.
Development Team
The Development Team are the people to create any part of the product. They aren't necessarily all software developers, but can include QA, design, devops, or anyone else working on the product.
Responsibilities include:
- Planning, estimating, and committing to the work they can complete in a sprint
- Working together to deliver the work they've committed to
- Participating in Scrum meetings
- Reviewing and improving their processes to increase their effectiveness and team efficiency
The Development Team get the final decision on what work they commit to delivering during a Sprint, they can't be overruled by the Product Owner or Scrum Master.
This includes the amount of work they commit to, and the work they pull from the backlog.
Ceremonies
Ceremonies (meetings) are held at key points in the sprint.
Sprint Planning
Sprint planning is held at the start of each sprint to plan the work to be done during the sprint.
During sprint planning, the team will:
- Agree on the sprint goal (what they want to achieve during the sprint)
- Select work from the Product Backlog to be completed during the sprint
- Split large pieces of work into smaller tasks
- Estimate the effort required to complete each task
Daily Scrum
The Daily Scrum (or stand-up) is a daily meeting where the development team gathers to discuss the progres of the sprint.
A common approach is for each developer to answer 3 questions:
- What did I do yesterday?
- What am I doing today?
- Is anything blocking me?
The Daily Scrum is time-boxed to 15 minutes, and should be held at the same time and place every day of the sprint.
Extended discussions are discouraged, and should take place after the Daily Scrum.
This is a meeting for the development team, while others may attend: they act as observers - only developers may speak.
Sprint Review
The Sprint Review is held at the end of the sprint to review the work completed during the sprint.
During the Sprint Review, the team will demonstrate the work they've completed to key stakeholders, and discuss any feedback they receive.
Sprint Retrospective
The Sprint Retrospective is held at the end of the sprint to review the sprint and identify ways to improve.
The team discuss what went well, what didn't go well, and what they can do to improve. They then agree on actions to take to improve the next sprint.
Some misconceptions
Scrum is rigid
Scrum is a starting point, it's designed to be flexible enough to be adapted to suit your team.
The basic framework is the same but the details can be changed to suit your circumstances:
- You might prefer to run weekly sprints, or as long as a month
- Definition of done is up to you
- You might combine the sprint review and retrospective into a single meeting
- Types of backlog items can be customised to your preferences e.g. user stories, bugs, spikes, etc.
The scrum master is a manager
The scrum master is a facilitator, they don't make any decisions or manage the team by default.
Frequently they won't even have a technical background, it's becoming more common for them to come from delivery or customer facing roles.
Scrum means individual progress can be tracked
Scrum focuses on the outcome of the team, not any individual developer.
The team as a whole is responsible for delivering the work they commit to, and can organise themselves as they see fit. This might mean that some developers work on frequent small tasks, while others work on fewer more complex ones, or even focus on unblocking other team members.
As long as the team is delivering, individual contributions are less important.
Coming to scrum
If you're new to scrum, especially if you're coming from a startup with no process or structure, it can be a big change.
Scrum does add plenty of benefits for engineers though:
Clear priorities
A key part of Scrum involves having a dedicated product representative (the product owner), who is responsible for setting the priorities for the team.
This means the developers can focus on their actual work, and won't be distracted by feature requests from other teams.
Autonomy
Scrum encourages the team to take ownership over their work, and the way they work.
While any engineering team still has to follow company process & guidelines, the scrum team still get a lot of say over their own work, and is responsible for planning, estimating, and delivering the work they commit to.
Transparency
A Scrum process is very open and visible, it's easy to s ee what the team is working on, and what they've completed.
At any time you're able to see the current status of the tickets being worked on.
Less churn
Scrum encourages the team to work in small batches of work, and to deliver working software at the end of each sprint.
If an idea doesn't work out, or if a feature ends up being less valuable than expected: it's easy to bin it (or scale it down) and move on.
Compared to a waterfall process, you're less likely to scrap several months of work at the end of a project if there's an issue (let's be honest, requirements are rarely set in stone)
Better communication
Scrum encourages the team members to communicate regularly, and provides opportunities or any issues & blockers to be raised.
This means that the developers can see upcoming work that product has planned, and product can see the current status of development work.
This helps to keep everyone on the same page and reduce any misunderstandings.
Continuous improvement
Scrum encourages the team to review your processes at the end of each sprint, and identify any ways to improve.
This means you can drop any practices that aren't working, and try any new ideas. It also means you can try new things without committing to them long term, you can try it for a sprint and drop it if its not working.