Scrum – our way to manage a team

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.

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.

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

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

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.

• 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.

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:

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

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.

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.

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).

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.

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:

• Product Backlog: description / Trello template
• Sprint Backlog: description / Trello template

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):

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.

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?

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.

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.

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:

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.

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.

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:

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.

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

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.

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.

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

1. Product Owner
2. Scrum Master
3. Team

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

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.

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.