Little Thorns is a cooperative bossfighter, where players have to stack up on top of each other to throw or be thrown to the boss’s weak spots.
The game is released on itch.io for PC: (https://igad.itch.io/little-thorns).
​
My role in this project was Scrum Master, Product Owner substitute and I have done a little bit of QA.
It has been quite a challenge as the team was 22 people big and of course all students, including me.
About the game:
The Process:
Communication Plan:
​
This communication plan was created by me at the Product Owner’s request. It contained all meetings that needed to happen, what they needed to be about, who participated and the when and wheres.
I had noticed very soon that not many team members ever looked at the document and that it lost its purpose because of that. Therefore, I decided to move this to the Discord where those who need to read it can be tagged and are then more likely to read it. The switch from a document to a discord channel worked very well for the team and I continued to use it for Project Exhibited due to its success.
Concept brainstorming for Little Thorns:
​
I have mainly facilitated and also participated in brainstorming for the concept of Little Thorns. This was quite the challenge due to my first time being part of such a big group as it can make meetings quite chaotic. Another challenge was the fact that a boss fighter is easily overscoped and thus many ideas had to be turned down.
Responsibilities:
-
Brainstorming for the concept
-
Communication Plan
-
Feature Teams
-
Collective Pipeline
-
Managed JIRA & created a Guide
-
Smoke Test
-
Contributed to the Post-Mortem
-
Team management
Genre: Bossfighter
Primary Role: Scrum Master
Platform: PC (Itch.io)
Engine: Unreal Engine 4
Project Duration: 8 weeks
Team Size: 22
Status: Released
​
Feature Teams:
​
I have been in charge of setting up feature teams as a Scrum Master. It often takes a bit of time to finish the puzzle; I always try to put someone who is willing and suitable for the job of lead, I try to keep the number of members per feature team between 3-7 if possible and do my best to make sure to give everyone the role and area they desire to increase motivation.
Collective Pipeline:
​
For this project, I have created a collective pipeline. I have noticed this might probably have been more beneficial for me than it was for individual team members as again, it was not looked at.
It did help me track down where exactly there were blockers and how that would influence others in terms of dependencies, which helped me to solve these problems again. I do understand that what I have made, as you can see down below, is perhaps not detailed enough to be used as a step-by-step guide of the process and too big to even get an idea of where to start.
Therefore, it may not be my proudest task of this project, yet I cannot deny that it has helped me a lot.
Managed JIRA & Created a Guide:
​
JIRA was a new tool for me when I started working with it on this project, but I had to try it as it was recommended by both our Product Owner and the teaching staff.
​
It gave me an understanding of terms I had never used before, like Epics & User Stories. Yet, when I started to understand JIRA in the first weeks, it became clear that the team did not.
It is crazy how many times I came by to bother people to please update their JIRA, so we could get a better sense of where the project was.
​
When I noticed that the team had forgotten how JIRA worked even after the demonstration, I created a guide for them to refer to whenever they got stuck. Even with all the effort I put into trying to convey JIRA to the team – it was in vain. It seemed like JIRA rather blocked the team instead of aided it, so to not make too much of a switch for the few weeks that were left, I printed the cards and made a physical scrum board out of it. It took away a lot of the digital efficiency, but at least it was not being a blocker anymore that was demotivating the team.
Smoke Test:
​
The smoke test was not a very difficult thing to do, except for me lacking that routine back then. It was only in the later weeks when I managed to set up a smoke test in the first place and also set a dedicated time when I would run through the build to test the features we aimed for.
Creating the feature list which this smoke test was based on really helped me understand the scope and doing the smoke tests gave me a clearer vision of where we are. In the end, the build is what we show and if there is something not in there before the deadline, it never will.
It gave me a lot of direction of where I might need to help out, reprioritize or could identify a risk.
Team Management
I have spent a decent amount of time on managing the team. This included mainly problem solving. Even though it was the least productive for me personally – the team really seemed to appreciate it and a lot of things were set into motion towards the right objectives whenever I spent time on short, but focused meetings with the team or individual team members.
