Ready to start working on a new development project? Great! But not everything is about coding. In fact, the most difficult part comes when several people have to work together towards the same goal, and without a way to visualize all the to-do's, things can often fall apart before they begin. That's where Scrum comes into play.
Scrum is a Project Management set of good practices that can be applied in any software project. In fact, it can be applied in any project that has a defined output. Scrum is based on iterations, or Sprints as they're called in the Scrum world. Each Sprint contains all the phases of a long-term project such as:
At the end of each Sprint, the product increment that could be achieved during the Sprint's time will be reviewed and validated and the cycle will begin again to build a final product in an iterative way that prevents team members from getting overwhelmed.
Those functional increments of the final product are specified in pieces called User Stories that are prioritized and sorted in a set of User Stories, called the Product Backlog. This backlog can change between Sprints, receiving new User Stories or changing their order. That is why Scrum is best known for its adaptability to change.
A high percentage of software companies worldwide are using Scrum in their development projects. However, a high percentage of them also apply Scrum "in their own way," which ends up with teams and directors wondering if the effort is worth it and if things would not work the same way going back to the more conservative approaches. Let's face it: Scrum works perfectly in the minds of Scrum trainers, but in reality, things are often not so obvious-and not everything can be found in Scrum guidelines.
Let's leave theory aside and focus on what a "real" project would be like from the conception of an idea to the delivery of the final product: a great and entertaining mobile video game. Let's go into detail of everyday difficulties the team has to face or the achievements they make every Sprint.
The Agile Manifesto is a formal proclamation of the four key values for Scrum practitioners. The first key principle says individuals and interactions should be considered over processes and tools. Are you ready to meet the individuals of this story and how they behave? Grab some sticky notes and let's start!
Company and Context
Gamelia Studio is our hypothetical and fictitious indie company based in, say, San Francisco. It was founded one year ago by three friends that were big video game fans and have worked for more than ten years in the software industry. During this first year, they have decided that they want to focus on mobile video games, mixing platforms and puzzles with 2D cartoon graphics. They have gathered a small team of qualified software engineers that will help them make their ideas a reality.
One of the founders has come up with the concept of their first video game: it will belong to the platform genre to be coherent with the company's own label, but its differentiating value will be its wide range of playable characters. Players will start as a little ant with few skills. As they earn points and finish levels, they will be able to become fish, birds, or even big animals, like dinosaurs. The final achievement of the video game will be to obtain the Human character. He would like this new video game to be named Darwin Was Right, but he's open to other title suggestions.
Do you want to meet the brains behind this idea? Our fictitious idea-man is Paul Brandt, and he will act as the Product Owner in this whole story while the other CEOs find ideas for different video games.
After several interviews, Paul has hired Kayla Ellison to become the Scrum Master of this first project. Kayla is very excited to start applying her knowledge in Scrum in a company from scratch.
Kayla has recommended starting the project with Sprint 0. This Sprint will be used to introduce the team and make them prepare the development environments, start defining user stories for Sprint One and make the team prioritize them.
Product Backlog Setup
The first step to achieve is to split the big project Paul has in mind into smaller, more manageable pieces. Paul knows how the final video game must look thanks to his expertise and the different market research projects he's done over the last year, but he needs help from Kayla to divide that idea into User Stories that the team can use. At the same time, these first refinement meetings between Paul and Kayla are very useful because it is the way that the Scrum Master is able to share the same vision as the Product Owner.
During their first meeting, Paul and Kayla get a huge and messy list of features, which starts the following conversation:
P: I am a bit worried that the project will get too long if we develop all these features. As an indie company, you know our budget is limited and I'm worried that when we launch the game, another company will have beat us to the punch with something similar.
K: Don't worry, Paul. If you have time and budget constraints, there is something we can do. Have you heard about the Minimum Viable Product or MVP?
P: Not exactly . . .
K: We just need to focus on what features make your video game unique and different from others. We will implement those user stories first and will launch the video game with a very basic functionality
P: Won't that make players feel the video game is unfinished?
K: Not if we select the key user stories right. You can also gather feedback from your users sooner and release new versions of your video game with things you know your players will love.
P: Sounds great. Let's continue working on the list of features the game will have.
K: Okay, but remember, it's not a list, and its name is the Product Backlog.
After three days of hard work, Paul and Kayla obtain the Product Backlog with the following characteristics:
- User Stories at the top are the ones to be implemented first (more important).
- As they will be implemented first, the User Stories have enough detail to be taken by developers and start working because:
- They follow the structure "As a <user>, I want to <action> so that <consequence>."
- They include positive and negative cases to explain the functionality without technical detail. They should focus on what the video game should do and not how it does it.
- They include a DoD, or Definition of Done, which is a checklist of tasks to be performed so the User Story can be considered closed. It is different from User Story to User Story.
- As the User Stories at the bottom will be implemented later, they can be bigger and don't have to be as detailed right away. These details will be achieved in future Sprints.
- Each User Story must provide added value to the video game once it is implemented. That is why they need to be seen as "pieces of functionality" and not simple tasks.
This is what the Product Backlog looks like in Sprint 0. Keep in mind that it has been simplified to make it understandable, only the User Stories that form an MVP (Minimum Viable Product) have been included in the Product Backlog stack:
The next step during Sprint 0 is to introduce the team. Kayla and Paul know Scrum requires cross-functional teams with more than three but less than nine people, according to the principles of Scrum. Otherwise, the management work would be overwhelming for one single Scrum Master and one single Product Owner.
The team has evaluated the technical needs of the project and have decided these are the people who will make Darwin Was Right possible:
Vishal Surinder, iOS Dev (24)
Janet Lisette, Android Dev (28)
Boyka Ivet, QA (30)
David Layton, Backend Dev (32)
Michael Zerah, Designer (34)
During the Kickoff meeting, guided by Kayla, everyone introduces themselves and asks the Product Owner a question about what he has in mind to start realizing the video game's vision.
Afterward, Kayla explains how they will apply Scrum because only Janet and David had previously worked with the Scrum practices:
- Sprints will be two weeks long (normally, this time-frame is between one and four weeks).
- They will maintain a visible Sprint board with the title of the User Stories that will be implemented in that Sprint. If there is a task ( an atomic assignment that can't be related to any User Story), it will be visible on the Sprint board and marked with another color.
- The details of each User Story (acceptance criteria, positive/negative paths, etc.) will be accessible in a software management tool like JIRA. Each User Story will be used as an artifact to ask the Scrum Master or the Product Owner questions if it is needed, so there is a record of the whole communication flow.
- All the team members will sit close to encourage communication and teamwork.
Team First Tasks
During Sprint 0, no functionality is implemented. Kayla explains to the team that the time left to finish this first Sprint must be used to prepare development and QA environments, have some conversations with Paul about how technical issues may affect the result, start designing the architecture, and prepare sketches for the real job.
This Sprint is used as a drill for the team to set these kinds of tasks on the Sprint board and get ready for the real deal . . .
Sprint Planning Meeting
Kayla: Good morning, mates. It's time to start working on Darwin Was Right. Let's have a look at the Product Backlog Paul has defined and prioritized.
Paul: The first User Story is, "As a player, I want to start a level and finish it, so I can have fun playing." This item is aimed at implementing a skeleton of the game that includes physics, interactions with objects, and a starting and ending point.
Janet: What will this first level be like?
Paul: As suggested by Kayla, I've already included a User Story to cover level design. This User Story is just to create a playable level without too much detail.
Kayla: Great. So guys, take your Planning Poker Cards and estimate in hours how much you think this User Story will need to be finished. Keep in mind the Definition of Done, as this story involves implementing logic on iOS and Android platforms, designing the basic character, and testing everything.
Each member of the development team (that excludes Kayla and Paul) tries to give an estimate by choosing one card from the deck of Planning Poker Cards:
David: I'm sorry, but I think this User Story will take more than a hundred hours, which is the highest number we have here. What should we do?
Kayla: It's okay. Sometimes User Stories are too big to be measured. These kinds of User Stories are called Epic User Stories and need to be split up into smaller ones.
Paul, as the Product Owner, takes the Epic User Story, "As a player, I want to start a level and finish it so I can have fun playing," and obtains the following smaller User Stories:
- As a user, I want to make my character move up, down, left, and right using the game pad so it advances through the level.
- As a player, I want my player to stand on solid objects so it can walk.
- As a player, I want my character to lose health when colliding with enemies so the levels are more dynamic.
- As a player, I want my character to kill enemies when I step over them so I can earn more points.
- As a player, I want to finish the level when I reach the goal, so I can see the End level screen.
The team estimates the stories, then Kayla calculates the average estimation, writes it on the post-it, and sticks it on the Sprint Board, which is a visual representation of the Sprint's progress. During the Sprint planning meeting, User Stories are broken down into tasks per role and assigned to specific members of the team. People from the development team are the only ones who decide how many User Stories they can complete in each Sprint.
After a long and productive meeting (with a coffee break of course!), this is how the Sprint Board looks, with two examples of User Stories that have been included in this Sprint's scope split into tasks with estimations per User Story.
Now that everybody knows what to do next, they can go back to their places and start working their magic.
A week has passed. It's already Friday and the development team is getting used to having one meeting every day. Now, the Product Owner is not usually invited to this meeting as the meeting is mostly about implementation details he does not need to know. This is because Kayla always forces it to last 15 minutes max, explaining that the team should focus on answering three basic questions:
- What did I do yesterday?
- What am I planning to do today?
- Is there anything blocking my work?
Bokya (QA) is the first person to start talking:
Boyka: Since all the tasks related to the first User Story are in the "To Verify" status, yesterday and today I have been testing the User Story as a whole and I can say it is working. Today, I will continue with the general test plan and nothing has blocked me yet.
Kayla: Have you checked that the US matches all the criteria defined in the Definition of Done? Boyka: I have. Can I move the User Story to Done status then?
Kayla: Sure. Okay Janet, what about you?
Janet: Yesterday, I solved the bug Boyka assigned to me. Today, I will start implementing the "character gets to goal" behavior. [...]
As team members speak and update the team regarding the status of their work, the Sprint Boards also get updated accordingly:
The end of the first Sprint has come and the whole team (including Paul, the Product Owner) gather in order to evaluate if the work that has been completed can be translated into a potentially shippable product increment. All the people from the company are welcome to see how the game evolves over time.
First, Kayla shows a demo of the video game, as it stands, on the two platforms:
Paul: I love it. You've done great work these past two weeks.
Kayla: As the Product Owner, do you give the go-ahead to the User Stories implemented this Sprint?
Paul: Sure. I'd just want a little adjustment in the physics. Maybe the character could move faster and jump higher. How can I move this petition to the team?
Kayla: We will create another User Story that includes this behavior and will add it to the Product Backlog. If you think it's important enough to be corrected during Sprint 2, you can add it to that Sprint's scope in the next Sprint Planning Meeting.
Paul: Great. I have to get used to the idea that the Product Backlog is something alive that never stops changing.
Kayla: I see you're grasping the concept! Anything else guys?
Michael: If you have a look at the Sprint Board, you'll see there's an unfinished User Story: "As a player, I want my character to kill enemies when I step over them so I can earn more points." Janet and Vishal finished their part of the User Story, but I didn't have the time to sketch all the enemies. How should we proceed with it?
Kayla: We will take this User Story to the next Sprint Planning Meeting and we'll re-prioritize it, keeping in mind part of the work is already done. There's no problem, Michael. Sometimes people tend to overestimate or underestimate how much it will take to implement something. You'll get better at estimating every Sprint.
Just after the Sprint review that focuses on the Product, only the development team and the Scrum master gather to celebrate the Sprint Retrospective that focuses on the way of working and how to improve it.
Kayla asks the team to grab three sticky notes and write in each of them something they would keep doing in future Sprints, something they have to stop doing, and something they should start doing to improve the overall process. Team members vote for the most valuable items.
Kayla reminds the team that they are now committed to fulfilling those items and leaves the Retrospective Board in a place visible from everybody's workplaces.
Sprint Before the Delivery
After several Sprints of hard work and improving processes every two weeks, the team works together like a well-oiled machine. Of course, there have been problems along the way. For example:
- Paul decided at the last minute that he wanted to include a new animal in the characters available before the delivery. Kayla and the rest of the team evaluated the work ahead during the Sprint and concluded it was impossible to make this new User Story fit. Despite Paul's complaints, the User Story entered in the Sprint backlog for the next Sprint.
- During development time, some User Stories did not have enough detail and the developers implemented what they thought was better for the product. This ended up with Paul requesting some needed changes during the Sprint reviews. In the end, the team learned that it was better to talk directly to Paul during the Sprint and write the conclusions of the conversation in the User Story itself.
- Sometimes Janet and Vishal could not finish their tasks because David had not finished his backend work. The team learned to foresee these dependencies between tasks and distributed them accordingly during the Sprint Planning to avoid people bottlenecking others.
Paul gives the final approval to Darwin Was Right's first delivery and publishes the video game on the Apple Store and Google Play. Now that they have delivered the Minimum Deliverable Product, the hard part is over. Paul will put together all the feedback from players and will filter and prioritize players' needs into User Stories for the team to work on.
Scrum does not say anything about celebrations, but that night, Paul, Kayla, Janet, Vishal, David, Boyka, and Michael had some beers together after work and propose a toast to celebrate their new video game, something that has the potential to catch the attentions of thousands of people.