Scrum - agile software development

Scrum – our way to manage a team

When we started to think about creating our own game we were faced with the following questions:

  • How can we find the right persons with the same vision and the needed skills?
  • Let’s say we’ll find the appropriate team members… what should we do next?
  • How should we manage the team?
  • What if some members are situated in different countries?
  • How do we stay connected and motivated?
  • How do we ensure that everybody does her or his job?
  • How should we plan the game and how do we guarantee that it’s done within the given time frame?

Questions over questions… with countless possible solutions! Sorry, we don’t have that one magical blueprint for you. Out of all these countless answers I can show you only one: our team building and team management strategy 😉

Scrum – agile software development

I heard about Scrum in college and it sounded great. I said to myself: if I ever work in a team, I want to put Scrum into practice. And so we did… partly.

Scrum is an agile software development framework. Agile means that the team knows that conditions can rapidly change in software development and that one just can’t plan for the future like it’s done in “traditional” project management. In short, agile software development advocates adaptive planning, evolutionary development, early delivery, and continuous improvement, and it encourages rapid and flexible response to change.

The Scrum team works self-organized and its members are in close contact with each other. The team works as a single unit to reach common goals. Practice shows that communication is the key for addressing changes as fast as possible. There are daily meetings (called ‘Daily Scrums‘) and plenty more meetings within a Sprint.

I wanna emphasize that in our current situation, we simply couldn’t implement Scrum in it’s pure form. We needed to loosen the restriction that the Product Owner and the Scrum Master are not allowed to assume the role of a “normal” developer. We don’t have the ressources to go without imporant skills needed for the actual development process. I also need to say that we by ourselves are still in the learning process. But I thought it may be interesting for other teams to see how it can/should/shouldn’t (decide by yourself) be done. I read a wonderful book about Scrum but it would have been great to also get some ideas of how to implement it in real life. So in the following section I’ll tell you how we try to use Scrum as an agile project management principle and how we adapted the process to fit our needs.

Product Backlog

The Product Backlog (PB) is the basis of the Scrum process – that’s why it’s being described first. It contains the so-called Backlog Items, which represent the requirements of the project. The Product Owner (PO) – one of the three roles in Scrum – is responsible for the maintenance of the Product Backlog and its items. Therefore he defines the requirements for the application/game.

When our PB was completely empty we started with defining the so-called Epics.

Epics

We started with a meeting where we went through the whole game and roughly identified the game’s components – our Epics. We’ve already had a concrete idea of how the game should look like and of what the player should be able to do. So we went through all aspects of the game and created a list. Here are some examples:

  • Player controls – movement and fight controls of the player
  • Combat system – hit point calculation, weapons, armor, …
  • Cutscene XY – short movies which emphasize key scenes
  • Sky – atmosphere of the setting, clouds, faraway objects, …
  • Dialog system – system which controls conversations between the player and non-player characters

The granularities of the Backlog Items of a Product Backlog

Backlog Items

Epics mostly cannot be done within a single Sprint (in our case a Sprint is a development cycle of two weeks). The Product Owner’s (PO) task is to take those roughly described Epics and to break them down into Backlog Items, which represent single requirements that can be implemented within a Sprint. If a Backlog Item is still too big, the PO has to find a way to split it again until each resulting part fits into a Sprint. This break-down-process should be repeated until enough Backlog Items for approximately the 2-3 upcoming Sprints are defined. Also dependencies between two or more Backlog Items and an optimal employment of each team member should be considered!

Then at least the Items for the next Sprint have to be described in detail. This means that the Items should meet the INVEST-criteria:

  • Independent: independence between Backlog Items ensures that the Items can be put into an appropriately order.
  • Negotiable: as long as a requirement isn’t part of the current Sprint it can be rewritten and even discarded.
  • Valuable: the requirement must be valuable for the customer (in our case the player)
  • Estimable: when the team estimates the single Backlog Items, too complex, too big or not fully understood Items can be identified
  • Small: a Backlog Item should add value to the project and should be viable in a single Sprint. Therefore it needs to have the proper size
  • Testable: requirements should have clearly formulated acceptance criteria

Definition of Done

The Definition of Done describes the criteria which need to be met to consider a Backlog Item as finalized. In our case the Definitions of Done are represented by check lists, which are attached to the Backlog Items. The individual list entries of the checklists describe states, which need to be achieved (check out this example). At the end of a Sprint the single team members present their implementations. During this process the Product Owner verifies if the presented solutions meet the Definitions of Done.

An unfinished Definition of Done

Product Backlog in short

  • Never complete or finished, it grows in line with the project
  • The only place where requirements are collected
  • Can be represented by simple paper charts or digitally by an Excel-sheet or other tools like Trello
  • Contains the Backlog Items
    • Fully described Backlog Items are Items which are currently under development and which can’t be changed anymore.
    • Backlog Items for the next 2-3 Sprints are not fully defined but show what’s coming next.
    • Epics are very roughly described Items which may be developed in the future. They are so far into the future that it’s not worth describing them in detail because the requirements will probably change completely.
  • The Backlog Items are prioritized according to their importance. This guarantees that they are done in the correct order.
  • Each Backlog Item is estimable and has Story Points attached to it. Story Points describe the effort of a Backlog Item related to other similar Items and don’t describe a fixed time unit like man days or something like that.
  • The Product Owner is fully responsible for the Product Backlog.

Tool: Trello

In the best case a Product Backlog is a haptic thing, like a collection of cue cards. But as you already know our team is spread all over the country/world. In our case a haptic PB doesn’t work, since it’s not accessable for each team member. That’s why we decided to use Trello – an online platform where you can organize teams and create boards. Within the boards you can create single lists and within the lists single cards can be defined. A card can contain a description, a deadline, attachments, lables and comments. In our point of view Trello provides everything a Product Owner needs for managing and maintaining a Product Backlog.

We prepared a small Trello-board which represents a template for a Product Backlog. It also includes a step-by-step instruction for how we maintain our Product Backlog. Simply click on the following screenshot:

trello product backlog template

Sprint

After the first setup of the Product Backlog, we started with the actual iterative Sprint-cycles. The following points describe a Sprint in a nutshell:

  • One Sprint-cycle takes one week up to one month (usually two weeks). Before the development process begins the team defines a duration for the cycle. From then on the agreed duration is fixed for the entire project.
  • It starts with a Sprint Planning where the team identifies the amount of work for the Sprint.
  • It ends with a Sprint Review and Sprint Restrospective in which the progress is reviewed and lessons are learned and improvements for the next Sprint are identified

Tool: Slack

For team communication during a Sprint we use a service called Slack. Like Whatsapp, it’s a text-based chat application, but with some nice additional functionalities. After adding team members to your chat-group you can create multiple channels and decide who is able to access a particular one. For example in our 25games-group we have public channels about general stuff regarding animations, graphics, and so on, but we also added channels about programming and marketing which only concern specific members of our team. Last but not least, compared to Whatsapp, media elements like images, text-files, videos, sounds, music, etc. can be commented and are much better organized.

slack overview

Arrange appointments

A Scrum Sprint starts with the Sprint Planning meeting, which in our case takes 4 hours. Therefore the first thing you always need to do is to arrange appointments of course. This is not as trivial as you might think. The team members do not automatically feel obliged to take a vote on an appointment. Additionally everybody is working freely, which means that there is no fixed schedule for working time and spare time. That’s why we arrange each meeting seperately. Nevertheless our goal is to do the Sprint Planning on Thursdays every other week.

Tool: Doodle

Doodle is the Scrum Master’s friend! We obliged each team member to install the Doodle-Apps on their mobile devices. In our case the Scrum Master chooses a date (usually Thursdays) and creates as many time suggestions as possible distributed all over the whole day. For instance he creates 4-hour-blocks starting from every hour of the day, beginning with let’s say 10am. Once done, Doodle allows to simply copy the settings and to create a new voting for the next Sprint.

The link created by Doodle is sent to the team-chat. A voting from a team member triggers a notification at the Scrum Masters mobile device. As a result he can see who already voted and can easily decide when to hold the meeting. Members who forget to vote need to be reminded by the Scrum Master as often as needed (optimally zero times :P).

1
2
3
Doodle: Voting for the next Sprint Planning
1

Title of the Doodle-survey

2

Click to open an overview of the results

3

Hourly suggestions for the Sprint Planning meeting. Durations are 4 hours

Doodle: Check the votes of your team members

Sprint Planning

8

hours for a one-month Sprint

4

hours for a two-weeks Sprint

2

hours for a one-week Sprint

The Sprint Planning begins with the presentation of the selected Backlog Items by the Product Owner. He explains the details as clearly as possible and the team discusses the Items until each team member fully understands the requirements. If needed use Planning Poker to estimate the effort of yet undiscussed Items. Then the team decides which Backlog Items will be implemented in the next Sprint. Lastly the Sprint goal has to be defined within one sentence. One example could be:

The goal of the Sprint is that the non-animated player can move in a fully designed and implemented environment

In the second half of the Planning the team talks about the possibilities of execution and which steps need to be done to reach the defined Sprint goal. The particular Backlog Items are broken down into small tasks which are registered in the Sprint Backlog. Each task must be able to be done within a single day! At this point it’s still possible to remove/add Backlog Items if it happens that the team miscalculated the amount of Items in the first part of the meeting. After this, the meeting is over and a part or all of the Sprint Backlog is created. If needed the rest of the Sprint Backlog has to be implemented on another day.

Tools: Skype + Trello

We use Skype to hold our team meetings and escpecially appreciate its possibility to do screen transmissions. In the case of a Sprint Planning, the Product Owner transmits his screen so that each team member can follow his oral pleadings. The Product Backlog and Sprint Backlog are both represented by Trello boards. For more details check out the following links:

Sprint Backlog

The Sprint Backlog consists of the Backlog Items, which have been selected during the Sprint Planning. During a Sprint the tasks, constituting the plan to reach the Sprint goal, can only be changed, refined or deleted by the team (neither by the Scrum Master nor by the Product Owner). The Sprint Backlog represents the current state of the Sprint and shows what is still required to reach the definied Sprint goal. In our Daily Scrums we update the Sprint Backlog and move tasks around. Tasks which should be edited next are moved into the “In Progress”-column of the Sprint Backlog whereas completed tasks are filed into the “Done”-column.

We prepared a simple Sprint Backlog template for you (click on the image below):

Columns of the Sprint Backlog

Daily Scrum

The Daily Scrum should be held every morning before each team member starts working. It’s not only a status update in which a manager inquires the current state of the project. It’s more like a meeting where every team member makes commitments to each other. Example: “Today I’ll finish the textures of our main character”. Then everybody knows, that tomorrow he/she will tell the team whether he/she could finish the task or not.

15

minutes – same for any Sprint duration

Properties:

  • Daily: The Daily Scrum meeting is held daily
  • Stand-Up-Meeting: Members are standing in a circle
  • Impediments: The Scrum Master listens to the team members and collects Impediments
  • Moderator: The Scrum Master moderates the meeting if needed
  • Questions: The Product Owner should passively attend the meeting to be up-to-date and to answer questions if needed
  • Topics: The team members tell each other:
    • What did I do yesterday?
    • What will I do today?
    • Are there any Impediments which need to be solved?

Modifications and used tools

Since some of us have a day job besides game development, we can’t do the Daily Scrum in the morning. That’s why we hold the meeting in the evening somewhere between 5 p.m. and 8 p.m. As a result, all of us make commitments not for the current day, but for the next day.

Each task in the Sprint Backlog is marked with an amount of effort written in brackets (e.g. “Blog: Scrum in practice (8)”). In the Daily Scrums we go through the tasks in the “In Progress”-list of the Sprint Backlog and revaluate the remaining effort needed for completion and attach the new value to the end task-title (“Blog: Scrum in practice (8) (4)“). If the effort changes, we tag the task with a label representing the current day. Tasks with zero remaining effort are moved into the “Done”-list. Lastly the Burndown chart is updated based on the new estimations.

Burndown chart

A Brundown Chart is a graphical representation of work left to do compared to the elapsed time. The x-axis illustrates a specific time interval, whereas the y-axis represents the remaining effort.

There are all kinds of different types of charts. The following list gives a little overview:

  • Release Burndown Chart
    • X-axis – time interval: Sprints
    • Y-axis – remaining effort: effort of the Backlog Items in the Product Backlog
    • Slope of the racing line: velocity of the team
    • Result: Prediction about the amount of Sprints required for completing the current release
  • Story Burndown
    • X-axis: days of the Sprint
    • Y-axis: remaining Backlog Items and their effort of the current Sprint
    • Result: Shows if the Items are completed in a steady manner, or if all Items are finished at the end of the Sprint. The latter can mean that the team is doing too much parallel work.
  • Task Burndown
    • X-axis: days of the Sprint
    • Y-axis: remaining tasks calculated for the Sprint
    • Result: Illustrates if tasks are completed steady-going, or if the amount of tasks finished during a Sprint day varies. The latter may mean that in the Sprint Planning complex issues were not correctly estimated or even some aspects were not considered.
  • Hours Burndown
    • X-axis: days of the Sprint
    • Y-axis: remaining hours of work needed for completing all tasks of a Sprint
    • Result: If the curve lies below the ideal line, the team can put effort into optimization tasks. But if the curve lies above the ideal line, this should be mentioned in the Retrospective.

Tool: Excel

We created an Excel sheet which illustrates a Task- and an Hours-Burndown Chart at once (download). After all tasks are definied and estimated, we count them and their total effort and put that into the “Day 1”-row. In each Daily Scrum we re-estimate the remaining effort for the tasks which have been edited and the chart is updated automatically by Excel:

Update your Burndown Chart

Sprint Review

At the end of each Sprint the team presents the achieved results to the Product Owner and other Steakholders and collects opinions, critique, suggestions and compliments.

4

hours for a one-month Sprint

2

hours for a two-weeks Sprint

1

hours for a one-week Sprint

This is the agenda:

  • Presentation: The team presents only the 100% successfully completed Backlog-Items live on the operative system, which could be shipped to the customer. There are no dummys, Powerpoint-presentations or screenshots allowed!
  • Definition of Done: The Product Owner decides if the presented content meets the Definition of Done of the related Backlog-Item.
  • Value: The team shows which value was added to the project by completing the Backlog-Item.
  • Incomplete: Each incomplete Backlog-Item is discussed, changed and represents a potential candidate for the next Sprint Planning
  • Velocity: Lastly the velocity of the team is determined by summing up the Story Points (effort) of the finished Backlog Items.

Tools: Trello

The Product Owner carefully listens to the presentations of the team members and verifies if the implementation meets the Definition of Done of the corresponding Backlog Item. In our case the Definition of Done is represented by a checklist where each list entry describes a state which needs to be achieved. Here’s an example:

An example of a Definition of Done

Sprint Retrospective

The Sprint Retrospective is held immediately after the Sprint Review. The team and the Scrum Master reflect the last Sprint and discuss how the internal Scrum-process can be improved.

3

hours for a one-month Sprint

90

minutes for a two-weeks Sprint

45

minutes for a one-week Sprint

This is the agenda:

  • Introduction (5%): Presentation of the time table for the meeting by the Scrum Master
  • Timeline (10%): Each team member reflects the last Sprint and writes down highs and downs happened during the Sprint (also private stuff is allowed). Thinking time: 3-5 minutes. Then the results will be presented member by member. No discussion is allowed!
  • Good (15%): What was good in the last Sprint? Same process as before: Thinking time of 3-5 minutes, presentation of results member by member, no discussion. The team should try to celebrate those points.
  • Bad (15%): What went wrong in the last Sprint? What should the team make better in the future? Same process: Thinking time of 3-5 minutes, presentation, no discussion
  • Discussion and Analysis (15%): Now the team is allowed to discuss the good and bad things
  • Plan (15%): The Scrum Master and the team create a plan for how the good things can be continued or made even better and how the bad things can be avoided or solved. If necessary, the Impediment Backlog is updated.
  • Buffer (20%)
  • Ending (5%): Closing words of the Scrum Master

Impediment Backlog

The Impediment Backlog is a list of impediments which prevent the whole team or specific team members from fully focus on their work. The Scrum Master is responsible for the Impediment Backlog and identifies obstacles on the way of productivity. But always remind yourself: Impediments should be eliminated not only collected. To do so we decided to always try to solve at least two impediments during a Sprint.

Impediment Backlog

Values

Scrum is based on five values. Values are needed to build a common basis where decisions can be made and further principles, strategies and practices can be developed.

Commitment

Be ready to commit yourself to reach a specific goal. Scrum gives you all the powers needed to fulfill this commitment.

Focus

Do your work! Put all your energy into the tasks you commited to. Don’t worry about other things.

Openness

All information about the project is visible for each team member.

Respect

Different people have individual backgrounds and experiences. So respect the distinction between you and the other members of the team.

Courage

Bravely commit yourself to a goal, act, show openness and expect respect

Roles

Scrum comes with a very lean role model. Only three roles are defining the Scrum-Team:

  1. Product Owner
  2. Scrum Master
  3. Team

Product Owner

The Product Owner is the one who determines requirements and checks the functionality, usability, quality and performance of implementations.

What the Product Owner should do:

  • Keeping the Product Backlog up-to-date
  • Representing the customer’s requests and therefore dealing with stakeholders
  • Prioritizing the Backlog Items
  • Passively attending the Daily Scrums
  • Answering questions of the team

What the Product Owner shouldn’t do:

  • Thinking that he is the boss
  • Moderating the Daily Scrums
  • Changing the Sprint Backlog during a Sprint
  • Working as a “normal” team member
  • Trying to overtake the Scrum Master’s role
  • Thinking that his responsibilities are important only at the beginning/end of the Sprint

Scrum Master

The Scrum Master is the soul of the Scrum process and takes care of the dynamics within the team. He is also a problem solver and has to pay attention to dynamics which could end in chaos.

What the Scrum Master should do:

  • Bearing responsibility for the Scrum process and its implementation
  • Being a facilitator and supporter
  • Striving for maximum benefit and permanent optimization
  • Eliminating impediments
  • Providing an optimal information flow between Product Owner and Team
  • Moderating Scrum meetings
  • Keeping an eye on the topicality of the Scrum artifacts (e.g. Sprint Backlog, Burndown chart, …)
  • Protecting the team against external influences during a Sprint

What the Scrum Master shouldn’t do:

  • Thinking that he is the boss
  • Giving the team exact instructions how the tasks have to be done and by whom
  • Working as a “normal” team member
  • Trying to overtake the Product Owner’s role

Team

The team is responsible for the implementation of the requirements. It forms the core of the Scrum process and – taken as a whole – the team represents one of the three roles in Scrum.

Characteristics of a Scrum Team:

  • Consists of 3-9 people (ideally 7)
  • Bigger groups are splitted into several Scrum teams
  • Interdisciplinary (programmer, artists, testers, … are working together)
  • Splits the Backlog-Items into tasks and creates the Sprint Backlog
  • Each member attends the Daily Scrum (daily of course…)
  • Each member knows the big picture of the project

What a Scrum Team shouldn’t do:

  • Defining requirements (this is the Product Owner’s job)
  • The working method of the individual team member shouldn’t be prescribed by the Product Owner
  • Ignoring the Sprint Backlog
  • Cutting oneself off from the rest of the team

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *

*