Thomas Carney on October 28, 2015 An Introduction to Scrum
Update: We've published a new blog post with the ultimate hands-on guide on how to implement Scrum in your team.
Scrum evolved out of a problem: software projects were coming in way over budget and way too late.
A team would have a software project that was supposed to take 18 months to complete. They’d spend 12 months on requirements, then start development for 6 months.
Suddenly, 2.5 years would have passed, and they’d release outdated software because the requirements had changed.
This was the waterfall model of project management.
Out of this frustration with failed projects, outdated new releases and missed deadlines, a few people started tinkering with different approaches to software development.
In 1986, a Japanese organizational theorist called Ikurjiro Nonaka wrote an article called the “New Product Development Game” in the Harvard Business Journal along with Hirkotaka Takeuchi.
In it, they argued that you should focus on speed and flexibility when developing new products, rather than a top-down defined planning process.
They drew a comparison to scrums in Rugby - groups of self-organizing team members working towards a common goal.
A few years later in the early 90’s, people such as Ken Schwaber and Jeff Sutherland started to test out new approaches to software development that they described as “scrum” methodologies.
So, What’s Scrum, Exactly?
Well, the best place for an introduction is right from the source. Ken Schwaber and Jeff Sutherland publish the “Official Scrum Guide” over at ScrumGuides.org. It’s the definitive statement of what “Scrum” is.
But scrum is often mixed in with lots of different concepts such as Agile development, Extreme Programming, Kanban and (lots) more.
Obviously, it all gets very confusing. You can get a good overview of the various concepts and how they link together from this subway map from Agile Alliance.
More Recommended Resources
The Ultimate Introduction To Agile Project Management
Why Would You Want Scrum?
The “ceremonies” or events of Scrum coupled with the artifacts are designed to promote an atmosphere of trust, a culture of continuous improvement and clear common goals.
This means you don’t have separate teams wearily working through requirements before “throwing it over the wall” for another team to work on.
The team works like a mini-company within the company. Upper management acts more in an investor role rather than micro-managing every decision.
That’s the promised land of scrum.
With Scrum, the team acts like a mini-company and upper management like investors.
What’s a Product Owner?
Product owners have the job of making sure the business is making the most of its investment. They’ll assess feedback from users, the business, and the team in creating new “user stories” for future development.
They’ll focus on setting the priority for new stories, and they’ll direct the team away from low-return work towards high-return work.
The difference between a product owner and a product manager
You might come across the division between product manager and product owner. What’s the difference?
Product managers will think more strategically about the product, whereas the product owner will be with the team on a day-to-day basis taking tactical decisions. Often, however, the two roles are combined into one.
In one extreme, you’ll have a product owner who spends her entire day with developers. She writes user stories, she sketches out ideas and she talks through problems with the team.
On the other extreme you’ll have a product manager who spends her day focused on the market. She might talk regularly with the VP of Sales. She’ll likely have a background in marketing, and she’ll interact with the marketing team regularly. In some cases, she might not be in the same location as the team, but rather on-site with clients or at the HQ.
Most product people will fit somewhere along the line between tactical day-to-day work and high-level strategic work.
Recommended Resources:
Agile Product Ownership in a Nutshell
Henrik Kniberg gives a great visual explanation of the role of product ownership.
20 Product Owner Antipatterns in Scrum
Scrum is not a silver bullet, and this article gives you an overview of some of the challenges that product owners will face.
What does a Scrum Master Do?
A good analogy for describing the role of a Scrum Masters is that they are the coach of the team. They make sure that the team lives by the values and practices of scrum. They work to remove impediments in the way of the team doing their work.
This puts the Scrum Master in an unusual position. They don’t have authority over the team. They can’t tell people what they should work on. Therefore, they are servant leaders rather than managers.
But they’re aren’t toothless tigers, either.
They can decide the process that the team will follow. They protect the team from outside interference during sprints. They’ll work with the product owner to make sure the product backlog is in good shape.
Recommended Resources:
Wikipedia Page on Servant Leadership
Example Checklist for Scrum Masters
Why Managers Make Terrible Scrum Masters
The Team Member Role
In most scrum teams, the team member will usually be a developer (although, some entire companies use scrum in all their divisions).
In Scrum, it’s a fundamental tenet that the team members are the highest authority on how the work should be done. They (and not some pointy-haired manager) can best estimate how long something should take, because they are the ones who have to do it.
This is a pretty radical notion!
Scrum also emphasizes cross-functional teams. That means team members don’t just work in their field of specialization. The focus is on the team coming together to finish the work they agreed to take on, rather than each team member doing their allotted functions.
Recommended Resources:
Introduction to the Team Role in Scrum
Who Should Scrum Team Members Report To?
The Daily Scrum or Daily Standup
This is perhaps the quintessential Scrum event.
Typically, the entire team will stand in a circle. Each person will say what they did yesterday and what they plan to do today. They’ll also state anything that’s preventing (blocking) them in doing their work.
The Scrum Master will time-box the event to 15 minutes, because you’re not suppose to solve problems during the standup. If you have problems, it’s best just to identify them and then discuss them after the standup.
Recommended Resources:
It’s Not Just Standing Up: Patterns for the Daily Standup Meetings
How to Do a Damn Good Daily Standup Meeting
The Sprint
In Scrum, you have a fixed period of time (often a month or less) in which to ship a product increment. This means you limit your investment to one month at a time, after which you can inspect and adapt for the next sprint.
It also means that you regularly put pieces of working software in the hands of your customers. You’ll get feedback from them that will inform what’s important for the future.
Recommended Resources:
Sprint Propaganda Posters to Fuel Your Sprint
Sprint Review and Retrospective
A big part of Scrum is reflecting on what went well during the sprint and looking for ways to improve. The motto is “inspect and adapt”.
The sprint review is an opportunity for the team to present their experience, outcomes and learnings from the sprint. Usually the product owner will invite key stakeholders to join the scrum team.
During sprint retrospective, the team looks at how the last sprint went and identifies bright spots and places for improvements.
Recommended Resources:
Introduction to the Sprint Review Meeting
How to Improve Your Sprint Retrospective
The Artifacts of Scrum
You’ll start to hear about “artifacts” in Scrum-speak. They aren’t something from Indiana Jones.
Artifacts in Scrum represent the work that has been done and provide transparency on important information. Artifacts include the product backlog and the sprint backlog.
The Scrum Board
In Scrum, you’ll hear about “information radiators”. The idea is to facilitate more communication with less interruptions. The scrum board is a great example of such an information radiator. It’s a board that shows all the tasks for the current sprint on board with various columns such as “To Do”, “Doing” and “Done”. It’s a great way to see the progress of the team towards the sprint goals at a glance.
Here’s how the scrum board would look like in Planio:
The Product Backlog
This is a list of all the unimplemented stories in a project that are not assigned to a current sprint. Any requirement for the product must be in this product backlog. The product owner is responsible for making sure the product backlog is up-to-date.
Recommended Resources:
Slideshare on creating a Product Backlog
The Sprint Backlog
The sprint backlog is the list of tasks that a Scrum team commits to completing during a sprint (usually 2 - 4 weeks). The product owner sets the priority from the stories in the product backlog, and the team breaks down the stories into tasks and estimates how many they can complete during the sprint.
Recommended Resources:
How to Save Time when Planning Sprint
How to Create Sprint Backlog Tasks by Ian Goldstein
Do you know of any valuable resources which helped you learn and implement Scrum? Share them in the comments! Oh, and do share this article, too.
Get an introduction to scrum with over 20 resources for learning more
