{"id":19902868,"url":"https://github.com/eficode-academy/lego-scrum-game","last_synced_at":"2026-03-05T17:14:04.148Z","repository":{"id":86541340,"uuid":"76803066","full_name":"eficode-academy/lego-scrum-game","owner":"eficode-academy","description":"A scrum team simulation with lego","archived":false,"fork":false,"pushed_at":"2017-03-24T10:04:07.000Z","size":7,"stargazers_count":5,"open_issues_count":1,"forks_count":2,"subscribers_count":4,"default_branch":"master","last_synced_at":"2025-01-11T21:23:11.317Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/eficode-academy.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2016-12-18T19:47:03.000Z","updated_at":"2021-06-07T07:23:43.000Z","dependencies_parsed_at":null,"dependency_job_id":"21d54310-670a-4ea7-a0ed-e0bf9ca4be42","html_url":"https://github.com/eficode-academy/lego-scrum-game","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/eficode-academy%2Flego-scrum-game","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/eficode-academy%2Flego-scrum-game/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/eficode-academy%2Flego-scrum-game/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/eficode-academy%2Flego-scrum-game/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/eficode-academy","download_url":"https://codeload.github.com/eficode-academy/lego-scrum-game/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":241329571,"owners_count":19945013,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-12T20:19:58.877Z","updated_at":"2026-03-05T17:14:04.079Z","avatar_url":"https://github.com/eficode-academy.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# Praqmatic Lego game\nAt [Praqma](http://praqma.com/) we have run quite a bit of training in Agile Task Management. Recently while doing [CoDe Academy](http://www.code-conf.com/academy2016/) we added the [LEGO scrum game](http://lego4scrum.com). \n\nThe reason that we have added the LEGO scrum game to our toolbox is\nthat it allows us to run a number of very short sprints with focus\nbeing on the managing the backlog. Introducing some malicious Product\nOwners also allows us to simulate the frustrations of dealing with\nreal world issues such as changing requirements and priorities,\nproduct owners that might not know what they want, know anything about\nthe domain or care about details.\n\nThe actual sprints lasts seven minutes, this is rarely where the\nactual learning is taking place, so it is nice that with the LEGOs we\ncan actually move closer to a finished product in such a short amount\nof time. Using LEGOs to induce frustration also removes a bit of the\ntension.\n\nThis document describes the implementation as used by Praqma of the LEGO scrum game platform from lego4scrum.\n\nIn this document we assume that we are working with a large (40+)\npeople, it should be trivially reducable to lesser groups.\n\n## The story\nYou have a vision. A vision of a city of grandeur, a large spaceport or a cozy garden. It is YOUR city. You don't have it entirely planned out, but you think you know what you want. You are the Product Owner from Hell. Luckily you have a pool of strong developers that will help you. They will work in teams using state of the art Agile Task Management methods! They will help you realize your ever-changing vision of this city.\n\n## Pre-game prep \n### Supplies \n* Lots of post-its - a pad or two per team\n* Pens\n* Something to provide a surface on which to place the cities - large pieces of paper will do\n* Boards, flipovers or big pieces of paper that you can put on a wall. These will hold the swim lanes\n* LEGO bricks - set #6177 is recommeded by lego4scrum. Anything that does not force the users into specific things will work. One box per team.\n\n### Setup\nMake sure that each team has a table to work. Each city should have a spot where the elements of the city can be placed after acceptance.\n\nEach team also needs to have a place to put their swimlane. It is nice if they have a wall near their \"workplace\"\n\nDepending on how many participants you have group the teams together in \"cities\". In our experience three teams to a city makes sense.\n\n## Running the game\n### Roles\n\n#### Trainer \n\nThe trainer is usually the person in charge of the\nevent. The trainer introduces the game. He describes the setting and the tools that are going on.\nThe trainer has the responsibility for keeping the pace.\n\n#### Product Owner\n\nProduct owner is also from the event team. It is best if there is one product owner per city/group of teams.\n\n#### Developer\n#### (SCRUM master)\n### Making teams\n\n### Naming teams \nMake sure to get team names, they are fun and serve as a nice break and garner team spirit.\n\n### Selecting team leads \nMake sure to elect team leads on each team so they can make sure that they have the right backlog. Also team-lead is the one both product owner and trainer communicates with.\n\n### joint backlog\nAfter teams are made, named and has elected a team lead we create the common backlog. What we need for our city. You can create it with the developers helping - again giving a nice community feel.\nMake sure that\n#### Suggestions for tasks\n\n* Multiple 1-storey buildings \n* fewer 2-storey buildings\n* Shop\n* Church\n* Hospital\n* School\n* Police Station\n* Fire Station\n* Park\n* Bridge\n* River ( Optional )\n* Amusement Park\n* Roller Coaster \n* Zoo\n* Bowling Alley\n* Dev shop\n* Intersection\n* Round-about\n* Roads\n* Pub\n* Parking\n\nMake sure to have each team lead gather the tasks that you agree upon, and produce the post-its for them.\n\nEach team have their own backlog which gets fed from the city backlog.\n\n### Game rounds\n#### Sprint planning\nThe product owner prioritizes each task in the joint backlog. \n\nThe PO has the team estimate how big each task is.\n\nEach team makes a \"deal\" with the PO of which tasks they can finish in this sprint.\n\nAt this point, it is important that the PO does not have an idea about the scope, or necessarily cares about implementation. The PO does not know everything, he just has a vision.\n\nThe priorities are not static, the product owner is allowed to change priorities and ask for new tasks.\n\nEach team grabs what tasks they believe they can finish and puts them into the team sprint backlog.\n#### Sprint\nThis is when the teams actually play with the legos, trying to produce solutions to the tasks that they have agreed with their PO on.\n\nIf they forget to things to the __in progress__ column the PO can go to the team, that is very likely extremely busy building, and ask them why they are not working. The PO of course does not know what they are working on if it is not on the board.\n\nA global clock may be used, or it may be up to the teams themselves to keep track of time. The important part of the exercise leader is to make sure that the sprints do not overflow the timeslot.\n#### Delivery\nAt the delivery the PO can ask the teams to show the products they have made either accepting or rejecting each task.\nTasks that are not done of cause stays in the team backlog. The PO of course tries to push the team to overcommit and add more tasks to their backlog.\n\n#### Retrospective\nWe are not doing agile if we are not trying to improve our process.\nThe retrospectives can be timeboxed or just last as long as is needed for each iteration.\nIt could reasonably be said that most of the learning takes place at the retrospectives and this means that time spent here is well spent.\n\nThere can be an advantage in timeboxing them in order to give a more cohesive experience for the participants.\nEspecially with multiple teams having them aligned in schedule is advantageous.\n\nSo far in the lego scrum games we've done the POs have been the ones driving the retrospectives.\nThis is probably a good idea if the games are relatively brief. \n\nIn a longer setting there could be a point in having the team leads or scrum masters run the retrospective and have the POs serve as coaches to the people running the retrospectives.\n\nThis is of course a more difficult assignment to do efficiently, for both teachers and students, but could provide a more solid and relatable understanding.\n\n#### Events\nA lot of external events can influence on how efficiently an agile team can work.\nWe are tinkering with the idea of having these events happen at random during a game.\n\nThis could give fun, more gamified approach rather than having all the troubles stem from the POs being incompetent or annoying.\n\nThis of course needs to be balanced with the events not obscuring the learning goals or just being useless distractions and frustrations.\n\nThe following events could be written on notes and be drawn at random points in the game:\n- Send a developer to another team\n- Switch team lead\n- Rotate teamleads between cities\n- A dev is sick and will not participate in the next sprint\n- PO is at a conference and can not receive any deliveries this sprint\n- Trade a team with another city\n- New policy from management: all buildings must be peer reviewed\n- Team lead is at meetings entire sprint and will not be building anything this sprint\n\n#### Learning goals for each round\nHere are some ideas for learning goals:\n - Small self organizing teams: start off by not dividing people into 4 groups but having them in one and look at the bottlenecks.\n - Minimize work in progress: try to make them work on more than they can chew, preassure them to overcomitting.\n - Communication with the PO.\n\n \n \n## Post-game evaluation\nAfter the game it is important that we reiterate what learning points we are trying to emphasize throughout this game.\nMost likely the students are confused and a bit annoyed with the product owners.\n\nThe following points are essential to bring forth: \n- It is not that far from real life experience\n- Small Tasks\n- Minimize Feedback Loop\n- Destroy your assumptions\n- Continous Integration / Feedback is an enable\n- Demand access to your PO throughtout the sprint\n\n\n## Outline for session of 2 x 45 minutes\n- Introduction (15 minutes)\n  - Who's got the roles\n  - Place people\n  - Make sure everyone has supplies\n- 3 iterations with retrospectives\n\n- Break\n\n- 3 Iterattions with retrospective\n- Post game evaluation (15 minutes)\n\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Feficode-academy%2Flego-scrum-game","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Feficode-academy%2Flego-scrum-game","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Feficode-academy%2Flego-scrum-game/lists"}