Some bumps in the road
…but it wasn’t anything we couldn’t handle. We were evicted from our classroom, a team member had to miss some time for personal reasons, and another team member was fighting the retopology monster. Overall, not a bad sprint. There were some things we were able to take away from it all. Hopefully it will make us all better and grow closer as a team. There is a new segment at the bottom. Food for thought. Just a little section where I talk about random production related things.
Quick hits
The team and I were caught off guard this week due to our classroom being suddenly remodeled. I had to relocate my team to a new location, find computers that met the needs of the artists, and helped the team reset-up version control on the new computers.
Created a list of talking points for Spencer to use during our end of sprint presentations. This list included items such as added features to the build, assets, known issues, and what our current plan is for our next steps in development.
Identified issues with our art pipeline not running smoothly in addition to team members not using our project tracking software correctly. This resulted in less than the planned amount of work being completed by our art team during this sprint. I am planning on having a conversation with all impacted parties during sprint planning next week. More details will be shared in the Closer look section and next sprint’s blog.
A closer look - Planning for SIX
As I mentioned in my last post, the team has decided to attempt to finish production of Crimson Herbicide in time for submission at the Seattle Indies Expo (SIX). This is a big challenge for the team to take on. At the time we made our decision, the shifted delivery date would mean a 20% reduction in production time. To help meet that delivery date, we adjusted the scope of the game that we would be delivering to SIX. For SIX we would be submitting the starting section, tutorial, narrative text, level one, and the first boss. We would save all non-SIX tasks to be completed after the delivery date. We would still have a few weeks to work on the game before AIE’s delivery date. So, in essence, we were not doing less work, just changing the priority of some tasks.
So, what did that look like? First, I needed to create a list of all the things we would need to complete for our build. In the past, I would take items from our deliverables section, break them down into tasks and create them in the backlog. I knew the direction, but I did not know the step-by-step path. Now, I needed to know all the steps we needed to take. With the end goal of ensuring we wouldn’t miss a step. I created this very simple excel document to track everything we needed to have done for submission. This excel document was shared with members of the team to ensure we were covering everything.
The next step in the process was to add all of these tasks into the backlog. This allowed me to tag all the tasks related to SIX. I was then able to create a design model, within our project tracking software, that allowed me to see the status of all SIX tasks at once. Additional information is also included in this model. Such as the total number of tasks, number of open tasks, estimation cost, logged work, and overall production completion percentage. With these tools, I am able to see where we stand on the project at any given time. I use this system to report our status to the team on a daily basis in our teams’ WIP channel. I believe it’s important for all team members to know where we stand with our project, and transparency is one of the pillars in Agile development.
We had ten weeks of production time when we started this journey to SIX. Using this design model, we need to complete 10% of our tasks every week to stay on track. At the end of the first week, we were around 20% completed. This was mainly due to the fact Ryan was able to complete a lot of his programming tasks much sooner than he anticipated. As I write this, at the end of the second week of SIX, we are sitting at 27%. At first glance, it might appear that we fell off the pace a little bit. I assure you that is not the case. During this week I broke up some larger tasks into smaller ones that will be completed in smaller chunks. This increase in overall tasking lowered the ratio between planned and completed tasks. But the team still remains on pace to complete this project on-time.
A closer look - Tracking how well we work
If you’ve been an avid reader of my blog, you’ll remember that I talked about the team wanting to use hours over other forms work estimation a few weeks back. This sprint is the first real test of how well we are able to predict and track our work. Overall, it was a good sprint. We learned a lot about our time estimation and took away some key learnings on how we can plan and execute better with our project tracking software. Before I go into some of those learnings, I would like to go over how I am organizing and planning the team’s time.
Each school week is two and a half days long. We have a half day Wednesday and full days on Thursday and Friday. Of course, no one works 100% of their time at school and work. There are breaks, meetings, and ‘quick’ conversations in the hall. I adjust for this by lowering the total number of ‘workable’ hours for each day. It looks something like this…
Wednesday - 2 hours
Thursday - 6 hours
Friday - 6 hours
End of sprint Friday - 4 hours
At the end of a two-week sprint, each team member will have the ability to complete 26 hours of work. I feel like this is a completely fair amount of work to expect on a per sprint basis. It is also the basis for the team’s expected throughput. Now, we make sure we are estimating time correctly.
To do this, I am comparing logged hours vs estimated hours at the end of the sprint for each department. If I need to dive a little deeper, I can do this for each team member as well. I can then also compare logged hours vs their capacity hours to ensure they are working efficiently. To explain a little more, let us take a look at Ryan’s production this sprint.
As you can see here, Ryan was able to complete 25.5 hours of work during this sprint. The estimate cost of the work he did was 48 hours. Of course, Ryan did not pull all 48 hours of work at the start of the sprint. Ryan was able to complete his tasks quicker than anticipated. Ryan then continued to pull more tasks into this sprint once he completed his current work. I would love to say that everything was perfect, and my 26-hour estimate is a thing of genius. Sadly, I think I just got lucky on this one and that’s just how the cards played out this sprint. Nevertheless, this does show the 26-hour estimate is a good base and I am now able to track performance.
Next, we are moving into our art team. Looking quickly at the numbers, you can tell it wasn’t the best sprint for the team. Several things came up during this sprint that effected their performance. Some of those things were unforeseen, others we just did not execute. We had a team member miss several days for a personal matter. Another team member was running into some technical issues and was spending a lot more time on a task than they initially intended. What we failed to execute on was proper task management. We were pulling multiple tasks at once, worked on those tasks for a little bit, did not complete them, and then moved on to another task. At the end of the sprint, we did not have a lot of ‘finished’ tasks to show. I know the art team was working. They were working hard, I watched them. But HOW they worked and how it is tracked and imported into the project is what matters here. This will be something that I will be talking with the team about during our next sprint planning meeting. Though this was not a stellar sprint for the art team, there is nothing here that we cannot fix and get better at. I know this team will knock it out of the park! We just need to get everyone on the same page and support them in the things they need. I will update future blog posts with their status and how things are going for them.
Last but not least, the design team. This group of people are responsible for the design, narration and sound for Crimson Herbicide. This group is going to be a little trickier to track tasking for. One reason is that I am part of this group, and I am counting towards the overall capacity. To that point, I am not tracking or tasking out any of my producer or product owner responsibilities. I view the tasks within the sprint and backlog for things that are going to be in the game. If that’s an asset, a feature or weapon balancing, great. I don’t believe that tracking conversations I have with individual team members, about a variety of topics, needs to be displayed for on a public board. There are things that I am doing that will make it into the game. Such as a handful of the prefabricated rooms we are using for the levels. Those tasks will be tracked and timed just like everything else. I guess that’s just a lot of words to say, “I am in a support role, and I don’t think those supporting actions need to be displayed in the main work area.” Second reason, a lot of what is left for design, outside of sound and narrative, are tasks that are very vague. The design team will constantly be working on combat balance, play testing, messing around with the room geo, and working on the overall user experience. Those things are not as cut and dry as ‘Is the enemy bear UV done?’ Of course, there are still tasks that they will need to accomplish, and I will track those. But I do not expect them to get on a consistent 26 hours of work per sprint in tasks. A lot of their time will be set aside to work on more ambiguous things. I am completely fine with the thought “I know Spencer is working on combat balancing this week. I do not need to track that.” And hey, I could be wrong. There might be a better way to track or deal with those things. I would honestly love to hear about it. Right now, I am in uncharted waters, and I am using my best judgement.
So…
With all of that being said, where do we stand? Overall, I think we are in a good place. To the right, the planned boxes are the estimated time that we currently have in our project tracking software for all tasks in each department to meet our SIX goals. The ‘actual’ box is how many sprints it would take to complete these tasks be going off past sprint performance. Clearly, I only have one sprint to base this off of, but that actual number will change once I get more data points. As you can see with the art team’s projection, if they perform the way they did this past sprint, they will not reach our deadline target. But, we still have plenty of time if I can get them back on track.
Capacity is telling me how many sprints it will take if each team member is able to complete 26 hours of work per sprint. I understand that might be a ‘perfect world’ and no blockers scenario, but again, it is another baseline that lets me know we should be good on time. As long as we perform.
Food for thought - Transparency
I want to use this new section for me to ask a rhetorical question or thought. It might be something that pops into my mind during a sprint, or something I might have had to deal with in the past. Just another window into my thought process and the random things in my head.
Transparency - One of the main pillars to Agile. If things are hidden, how are people going to know there is a problem and how will they fix/improve them? But where is the line between transparency and human interaction? I want to be transparent to the team and also not alienate a team member.
Example thought: Let’s say that I have a member of the team who isn’t performing well. A designer who is working on a UI screen for the pause menu. Their work is not dependent on anyone else, and their work is not blocking someone else. The UI screen goes through a sprint and is not completed. No progress is made. I am going to track that. I am going to document that. I will have a conversation with the team member about that. All tracking software will show the UI screen is behind. But where does the transparency end? Do I mention the uncompleted task during our next stand up or sprint planning meeting? I say no. That team member might feel like they are being called out or ‘put on blast.’ Others might say that as long as that standup meeting was done in a professional manner, we need to be transparent how this person is performing.
As I write this, I am thinking I would try to walk a fine line. I would do what I thought I would need to, to address the situation with the team member. I would track it and display it. I would talk about it if asked. But I wouldn’t bring attention to it. When not knowing what the correct answer is, I would try to respect the individual.
