Scrum is like a box of chocolates…chocolate is always worth a try! (unless you’re a dog)
Why should I care about…Scrum?
Scrum offers the most popular, battle-tested recipe for building a successful product as a team. The product can be anything from a simple software to a Mars spaceship. You don’t need to reinvent the wheel - Scrum tells you what most (hyper)productive teams do to:
- stay productive and creative = happy team members 😊
- deliver a product that end users want = happy customers 😊
- minimize a waste of time and money = happy business owners 😊
Why would anyone create Scrum?
Scrum was a natural answer, to the problem in software development, that came in 1993. The problem was the waterfall model — a development process that could last years before customers got any value out of the final product. The waterfall model can be broken down into 6 steps, where each step can be started only after the previous step has been completed:
- business people => create a DETAILED requirements specification
- architects => create a DETAILED system architecture with all kinds of fancy diagrams
- developers => can finally start coding
- testers => get the finished code and can start testing the system
- devOps => a long, long time has passed and the system can be deployed
- now make sure it still works the next day
The main flaw with the waterfall model is that it doesn’t take into account any uncertainty. Everything is planned down to the last detail at the beginning, and it is assumed that the plan is correct. However, the initial plan is always incorrect and it’s complicated to change it later in the process. That’s why Scrum comes to save the day…or years of wasted effort and
The Scrum recipe
What if you could avoid wasting the precious years and ”billions and billions”? Well, it turns out you can. Work in Scrum is done in 1–4 week cycles called Sprints. 2 week Sprints are most common(about 80%) but 1 week is more suitable for 2–3 month projects. At the the end of each Sprint the team delivers a part of the product that is done and ready to be used by end users. A Sprint can’t be longer than 4 weeks, which means you can’t waste more than that, even if the team delivers something completely different than what customers want. That’s not all, Scrum has more tools to minimize the waste and maximize success far more.
From a pile of papers to a visible product value
You start a project with writing a contract/agreement document between you and customer. Then the document has to be broken down into smaller pieces, a.k.a user stories. A user story answers 3 essential questions:
As a <Who is this task being done for?>,
I want <What do we want done in the first place?>
so that <Why does this user want this thing?>.
Why is the key part because the team may know a better, easier and faster way to achieve the very same goal.
Each user story has to have 3–7 acceptance criteria — a list of conditions that say when the story is done. If you end up with less than 3, you need to specify them better. If a story has more than 7 criteria, break the story to multiple smaller stories. You can see a few examples on https://tech.gsa.gov/guides/user_story_example/.
User stories are written by a person that knows how to translate the requirements into true, meaningful value, a.k.a a Product Owner. A Product Owner can ask the development team to participate in writing user stories.
Then user stories are estimated in relative units, a.k.a story points, by the development team. The most common estimating technique is Planning Poker.
You have all the user stories properly estimated with story points, the Product Owner prioritized them according to value they bring to end users and you can start your first Sprint! 🚀
Sprint Planning meeting is the first step in each Sprint. The team looks at the list of user stories, a.k.a Backlog, and decides how many they can accomplish this Sprint. The user stories should be estimated before the Sprint Planning, otherwise there can be questions that can’t be answered in the meeting.
Pulling stories from the Backlog should get easier after 3–4 Sprints, when you have a steady velocity. Velocity in Scrum means: how many points the team can finish in a Sprint. If your velocity is 50 points, you should pull stories worth 50 points or slightly more.
Daily bread à la Scrum
The development team has to collaborate well to push the user stories to the sweet end together. Scrum achieves this with a daily meeting called Daily Scrum or Daily Stand-up. This meeting is held every day at the same time and should not take more than 15 minutes. If it’s longer than 15 minutes, something is wrong.
In Daily Stand-up each team member should answer 3 questions:
1. What did you do yesterday to help the team finish the Sprint?
2. What will you do today to help the team finish the Sprint?
3. What obstacles are getting in your way?
Did we get it right?
At the end of each Sprint, Scrum gives you an opportunity for presenting what you have accomplished. The meeting for this purpose is called the Sprint Review. Your work can be shown to the Product Owner, end users, people who pay for the project, or anyone who can give you meaningful, valuable feedback.
The Sprint Review can show if you’re heading in the right direction. It can also tell you what the end users value most — you might have to reprioritize the Backlog and/or create new user stories.
Good, better, best
You can never reach perfection with Scrum. Not because Scrum is bad, but you should always aim for improvements for the next Sprint. In the very last meeting of the Sprint — the Sprint Retrospective — you should look back and answer one main question:
What is the little improvement that can be done right away that will make things better?
You should leave the Sprint Retrospective with 1–3 improvement actions for the next Sprint. In the next Retrospective you can then assess the action points and see if you managed the improvements.
The world never sleeps
You’ve just read the necessary minimum for starting to do Scrum. You know that you create and estimate user stories at the project start. But what if the needs/wishes of end users change after you’ve already started? Don’t worry, Scrum got you covered. 💪
Every Sprint you can schedule a meeting — the Backlog Refinement — where you review the Backlog. You can discuss new user stories, remove irrelevant stories, re-estimate and re-prioritize the stories.
Extra: why is it called Scrum?
Jeff Sutherland, the creator of Scrum said:
The term comes from the game of rugby, and it refers to the way a team works together to move the ball down the field. Careful alignment, unity of purpose, and clarity of goal come together. It’s the perfect metaphor for what I want teams to do.
If you’d like to know the whole story behind Scrum and all the whys, there’s nothing better than the explanation straight from the author of Scrum:
After Ken Schwaber and I wrote "Software in 30 Days" I felt we didn't have enough stories about Scrum outside of…
You may like
How to Publish Content With the Instagram Graph API
Share Instagram posts from a React app — Step by step guide
How to Build a Chrome Extension With React, TypeScript, and Webpack
From creating a boilerplate to publishing a complete extension to Chrome Web Store