Camp Champ
Camp Champ
Role
Producer
Duration
14 weeks
Team Size
14 developers
Engine
Unreal Engine
Platform
PC
Genre
Couch Play
Role
Producer
Duration
14 weeks
Team Size
14 developers
Engine
Unreal Engine
Platform
PC
Genre
Couch Play
Camp Champ is a 2v2 capture the flag game with goofy combat and a 1930s art style. In this project I learned how to produce a game from a concept to a final product which was released on itch.io. My responsibilities were to break down the scope, organise scrum rituals, anticipate and manage risks, deliver report presentations and manage Jira.
Camp Champ is a 2v2 capture the flag game with goofy combat and a 1930s art style. In this project I learned how to produce a game from a concept to a final product which was released on itch.io. My responsibilities were to break down the scope, organise scrum rituals, anticipate and manage risks, deliver report presentations and manage Jira.
Role
Producer
Duration
14 weeks
Team Size
14 developers
Engine
Unreal Engine
Platform
PC
Genre
Couch Play
Camp Champ
Role
Producer
Duration
14 weeks
Team Size
14 developers
Engine
Unreal Engine
Platform
PC
Genre
Couch Play
Role
Producer
Duration
14 weeks
Team Size
14 developers
Engine
Unreal Engine
Platform
PC
Genre
Couch Play
Camp Champ is a 2v2 capture the flag game with goofy combat and a 1930s art style. In this project I learned how to produce a game from a concept to a final product which was released on itch.io. My responsibilities were to break down the scope, organise scrum rituals, anticipate and manage risks, deliver report presentations and manage Jira.
Role
Producer
Duration
14 weeks
Team Size
14 developers
Engine
Unreal Engine
Platform
PC
Genre
Couch Play
My Contributions
My Contributions
My Contributions
Project breakdown
Project breakdown
Project breakdown
Being a producer, one of the first tasks I had to complete was to break down the whole project. My approach to this was firstly to sit down with the leads and make a breakdown proposal to the rest of the team with prioritization so that the team can break it down more to user stories which I checked in the end. The final tasks were moved to Jira which we used as our project management tool.
Being a producer, one of the first tasks I had to complete was to break down the whole project. My approach to this was firstly to sit down with the leads and make a breakdown proposal to the rest of the team with prioritization so that the team can break it down more to user stories which I checked in the end. The final tasks were moved to Jira which we used as our project management tool.
Being a producer, one of the first tasks I had to complete was to break down the whole project. My approach to this was firstly to sit down with the leads and make a breakdown proposal to the rest of the team with prioritization so that the team can break it down more to user stories which I checked in the end. The final tasks were moved to Jira which we used as our project management tool.
Jira setup
Jira setup
Jira setup
One of my production responsibilities was to set up Jira in a manner that is suitable for the team and how we agreed on organization of the project. I did it by setting up the kanban board used for standups, setting up the sprints and bug reporting. I have structured the kanban board in a way that suits my standup procedure to have visible sprint backlog (labeled as to do), tasks that are in progress, in review and done.
One of my production responsibilities was to set up Jira in a manner that is suitable for the team and how we agreed on organization of the project. I did it by setting up the kanban board used for standups, setting up the sprints and bug reporting. I have structured the kanban board in a way that suits my standup procedure to have visible sprint backlog (labeled as to do), tasks that are in progress, in review and done.
One of my production responsibilities was to set up Jira in a manner that is suitable for the team and how we agreed on organization of the project. I did it by setting up the kanban board used for standups, setting up the sprints and bug reporting. I have structured the kanban board in a way that suits my standup procedure to have visible sprint backlog (labeled as to do), tasks that are in progress, in review and done.
Team organization
Team organization
Team organization
In the beginning of this project the first thing I have done was to have a meeting with the team proposing them how I would like to organize the production pipelines and ultimately to get their agreement since my main belief is that each team member should agree with the procedures and have the possibility to say no if they do not like something to create a safe environment that everyone can focus in.
Sprint plannings
Prior to greenlighting every sprint, I did sprint planning with the team that took approximately one hour. I asked each team member to choose tasks that they would like to work on that sprint (2 weeks). Once every team member had chosen their tasks, we collectively looked at all the tasks that the team wanted to complete, and I asked them whether we could complete them. If the answer was no, we moved some tasks back to the backlog until the answer was yes. The next step was to create a sprint goal which would summarize the tasks that the team chose to complete. Once the team formulated the sprint goal, I sent the sprint goal to our stakeholders (teachers in our case) to approve the sprint goal and greenlight the sprint and start the sprint on Jira.
Meetings
My proposal to the team was to have meetings in a structured manner both before and during the meeting. We agreed to have meetings announced at least 24 hours prior to the meeting with specific agenda for the meeting shared with the list of attendees that sign up for the meeting. During the meeting I as the producer was hosting the meeting meaning going through the agenda keeping track of time and managing who gets to speak when. The attendees were discussing the possibilities of each agenda item and then I recapitalized the point and concluded it. We also had note-taker that took notes which were then shared to the rest of the team.
Reviews & Retrospectives
These rituals were crucial for me as producer since these were the times where the team aligns and discusses how to move forwards and solve problems that came up. Reviews being focused on the product were structured to answer questions like: “Do we like the game? What is missing? Should we change something?” I organized retrospectives with asking the team to write down three things they liked and three things they disliked about the procedures in the team and answer the questions: “Are we happy with how the sprint went?”
In the beginning of this project the first thing I have done was to have a meeting with the team proposing them how I would like to organize the production pipelines and ultimately to get their agreement since my main belief is that each team member should agree with the procedures and have the possibility to say no if they do not like something to create a safe environment that everyone can focus in.
Sprint plannings
Prior to greenlighting every sprint, I did sprint planning with the team that took approximately one hour. I asked each team member to choose tasks that they would like to work on that sprint (2 weeks). Once every team member had chosen their tasks, we collectively looked at all the tasks that the team wanted to complete, and I asked them whether we could complete them. If the answer was no, we moved some tasks back to the backlog until the answer was yes. The next step was to create a sprint goal which would summarize the tasks that the team chose to complete. Once the team formulated the sprint goal, I sent the sprint goal to our stakeholders (teachers in our case) to approve the sprint goal and greenlight the sprint and start the sprint on Jira.
Meetings
My proposal to the team was to have meetings in a structured manner both before and during the meeting. We agreed to have meetings announced at least 24 hours prior to the meeting with specific agenda for the meeting shared with the list of attendees that sign up for the meeting. During the meeting I as the producer was hosting the meeting meaning going through the agenda keeping track of time and managing who gets to speak when. The attendees were discussing the possibilities of each agenda item and then I recapitalized the point and concluded it. We also had note-taker that took notes which were then shared to the rest of the team.
Reviews & Retrospectives
These rituals were crucial for me as producer since these were the times where the team aligns and discusses how to move forwards and solve problems that came up. Reviews being focused on the product were structured to answer questions like: “Do we like the game? What is missing? Should we change something?” I organized retrospectives with asking the team to write down three things they liked and three things they disliked about the procedures in the team and answer the questions: “Are we happy with how the sprint went?”
In the beginning of this project the first thing I have done was to have a meeting with the team proposing them how I would like to organize the production pipelines and ultimately to get their agreement since my main belief is that each team member should agree with the procedures and have the possibility to say no if they do not like something to create a safe environment that everyone can focus in.
Sprint plannings
Prior to greenlighting every sprint, I did sprint planning with the team that took approximately one hour. I asked each team member to choose tasks that they would like to work on that sprint (2 weeks). Once every team member had chosen their tasks, we collectively looked at all the tasks that the team wanted to complete, and I asked them whether we could complete them. If the answer was no, we moved some tasks back to the backlog until the answer was yes. The next step was to create a sprint goal which would summarize the tasks that the team chose to complete. Once the team formulated the sprint goal, I sent the sprint goal to our stakeholders (teachers in our case) to approve the sprint goal and greenlight the sprint and start the sprint on Jira.
Meetings
My proposal to the team was to have meetings in a structured manner both before and during the meeting. We agreed to have meetings announced at least 24 hours prior to the meeting with specific agenda for the meeting shared with the list of attendees that sign up for the meeting. During the meeting I as the producer was hosting the meeting meaning going through the agenda keeping track of time and managing who gets to speak when. The attendees were discussing the possibilities of each agenda item and then I recapitalized the point and concluded it. We also had note-taker that took notes which were then shared to the rest of the team.
Reviews & Retrospectives
These rituals were crucial for me as producer since these were the times where the team aligns and discusses how to move forwards and solve problems that came up. Reviews being focused on the product were structured to answer questions like: “Do we like the game? What is missing? Should we change something?” I organized retrospectives with asking the team to write down three things they liked and three things they disliked about the procedures in the team and answer the questions: “Are we happy with how the sprint went?”
Risk management & QA
Risk management & QA
Risk management & QA
Another responsibility of mine was to manage risks and try to eliminate any inconvenience for the team. I adapted Prince2 risk log for this which I managed with the leads after each sprint review and retrospective since these are the meetings where problems and risks are defined. For each risk we evaluated the possibility and severity of the risk to determine our solution and assigned a person accountable for the given risk. Additionally, I took upon the role of quality assurance with creating test plans which were executed after each build review.
Another responsibility of mine was to manage risks and try to eliminate any inconvenience for the team. I adapted Prince2 risk log for this which I managed with the leads after each sprint review and retrospective since these are the meetings where problems and risks are defined. For each risk we evaluated the possibility and severity of the risk to determine our solution and assigned a person accountable for the given risk. Additionally, I took upon the role of quality assurance with creating test plans which were executed after each build review.
Another responsibility of mine was to manage risks and try to eliminate any inconvenience for the team. I adapted Prince2 risk log for this which I managed with the leads after each sprint review and retrospective since these are the meetings where problems and risks are defined. For each risk we evaluated the possibility and severity of the risk to determine our solution and assigned a person accountable for the given risk. Additionally, I took upon the role of quality assurance with creating test plans which were executed after each build review.
Presentations
Presentations
Presentations
Preparing and delivering presentations to the team, stakeholders and public was crucial to me to gain feedback outside of the team to steer direction when needed since stakeholder collaboration is important in Agile. I spent time communicating with the stakeholders what they would like to hear along with the team what information they want to provide to structure all information that I then delivered in form of presentation which taught me how to organize and present ideas.
Preparing and delivering presentations to the team, stakeholders and public was crucial to me to gain feedback outside of the team to steer direction when needed since stakeholder collaboration is important in Agile. I spent time communicating with the stakeholders what they would like to hear along with the team what information they want to provide to structure all information that I then delivered in form of presentation which taught me how to organize and present ideas.
Preparing and delivering presentations to the team, stakeholders and public was crucial to me to gain feedback outside of the team to steer direction when needed since stakeholder collaboration is important in Agile. I spent time communicating with the stakeholders what they would like to hear along with the team what information they want to provide to structure all information that I then delivered in form of presentation which taught me how to organize and present ideas.
Main Takeaways
Main Takeaways
Main Takeaways
The point system has many benefits like taking into account members getting sick or making it easier to put tasks in perspective to team capabilities. On the other hand, it requires time for each team member to sit down and do those estimations properly. Other than that, if team members do not understand point estimation well, it becomes effective once people get used to it and understand the reasoning behind it.
People do not like to under-scope. Team members had a feeling that if we planned for more, we would have a better product in the end. This depends on several factors. If we under-scope the team has a stress-free mindset because we will deliver the goals we set. If we over-scope we push for a potentially better product disregarding stress. There is a very fine line between these two approaches and people will always feel it was either too little or too ambitious.
Having the final say in decisions comes with a great responsibility. As a producer, I was the one to make the last decision and it is really hard to find a good approach. It is crucial to allow everyone to have their say and time to think especially when things get heated and time is pushing. However, as I heard from someone if you do not have time to stop and think, it is probably the time to stop and think.
The point system has many benefits like taking into account members getting sick or making it easier to put tasks in perspective to team capabilities. On the other hand, it requires time for each team member to sit down and do those estimations properly. Other than that, if team members do not understand point estimation well, it becomes effective once people get used to it and understand the reasoning behind it.
People do not like to under-scope. Team members had a feeling that if we planned for more, we would have a better product in the end. This depends on several factors. If we under-scope the team has a stress-free mindset because we will deliver the goals we set. If we over-scope we push for a potentially better product disregarding stress. There is a very fine line between these two approaches and people will always feel it was either too little or too ambitious.
Having the final say in decisions comes with a great responsibility. As a producer, I was the one to make the last decision and it is really hard to find a good approach. It is crucial to allow everyone to have their say and time to think especially when things get heated and time is pushing. However, as I heard from someone if you do not have time to stop and think, it is probably the time to stop and think.
The point system has many benefits like taking into account members getting sick or making it easier to put tasks in perspective to team capabilities. On the other hand, it requires time for each team member to sit down and do those estimations properly. Other than that, if team members do not understand point estimation well, it becomes effective once people get used to it and understand the reasoning behind it.
People do not like to under-scope. Team members had a feeling that if we planned for more, we would have a better product in the end. This depends on several factors. If we under-scope the team has a stress-free mindset because we will deliver the goals we set. If we over-scope we push for a potentially better product disregarding stress. There is a very fine line between these two approaches and people will always feel it was either too little or too ambitious.
Having the final say in decisions comes with a great responsibility. As a producer, I was the one to make the last decision and it is really hard to find a good approach. It is crucial to allow everyone to have their say and time to think especially when things get heated and time is pushing. However, as I heard from someone if you do not have time to stop and think, it is probably the time to stop and think.
Gallery
Gallery
Gallery
Other Projects
Other Projects
Other Projects
© Copyright 2023. All rights Reserved by Martin Bazlekov.
© Copyright 2023. All rights Reserved by Martin Bazlekov.
© Copyright 2023. All rights Reserved by Martin Bazlekov.
© Copyright 2023. All rights Reserved by Martin Bazlekov.