Understanding the Star Citizen and Squadron 42 Roadmaps

I’ve been a software developer and all-around computer guy for a while now. I’ve paid quite a bit in blood, sweat, and mostly tears learning how this stuff works. My hope with this article is to share some of that hard-earned knowledge with people outside of the magical world of software development. This article is an attempt to help you understand what goes on behind the scenes whenever the Star Citizen Development Roadmap receives an update. A couple of caveats first:

Caveat 1: I’m not an employee of Cloud Imperium

I’m just a guy who pays for his spaceships by writing software as his day job. I don’t know anyone personally at CI, and I have no inside knowledge of what goes on behind their very closed doors. CI uses commonly used, industry standard software development methods, therefore, I can make an educated guess as to what’s happening behind the scenes based on the things they tell us in official communications.

Caveat 2: This is not an Agile/Scrum workshop

This is not a workshop on Scrum methodology and it’s not intended to be. Nor is it intended to be for other software professionals. It’s intended to be something your mom, uncle, or friend can read to understand some of the decisions being made that affect the development timeline of Star Citizen. If you’re a software professional, familiar with Scrum, your constructive feedback is welcome to help improve this document, but please remember people like YOU are not the intended audience.

One more small thing to note: While I’ll be discussing Star Citizen almost exclusively in the examples used in this article, all of this information also applies to the development roadmap for Squadron 42.

Now, with that out of the way, let’s begin with a hypothetical example.

Part 1: What Do You Want Me To Do?

As I go through this example, I’ll be introducing some vocabulary words but I’ll try to keep things as jargon free as possible. So picture this:

Today is our first day on the job as new employees at Cloud Imperium (Nice! Congrats to us! We’re awesome! Do we get free ships???) Chris Roberts himself comes over to us and says he wants to put US in charge of adding a new ship to the game, even though we’re new, because he’s heard that we’re so awesome. In fact, we’re goin to be put in charge of adding the Carrack into the game!

Carrack is life!

Adding this fan-favorite ship into the game is going to take a great deal of work, so we’re going to have to plan this out ahead of time so we don’t miss our deadlines. To understand HOW were going to go about planning the release of this ship, let’s start with some simple vocabulary.

So the first vocabulary word is: Jira

Jira, quite simply, is just a piece of software with a funny name. (Techies like to give software strange names for some reason ??‍♂️). Jira is actually used by many software development companies all over the world. In fact, I use it every day myself at my day job. It’s a program/website that allows your team to keep track of all the work that needs to be done on software projects. You can set due dates, assign tasks to certain groups, forecast when projects will be complete, view all kinds of confusing charts and graphs, it’s chock full of relatively boring (but useful) project management stuff. The key thing to remember is this: it’s the software used by CI to manage and track all the work done on Star Citizen.

Epic, Story, and Task

The next three vocabulary words are presented from “largest” to “smallest” since they’re all closely related. Hopefully that will make sense in a second:

The first of these three terms is: Epic.

You can think of an epic as a big box, or a bucket of work; some sort of large container to organize a bunch of related tasks. It’s generally related to a specific goal like “Create the Anvil Carrack”. Epics are big enough collections of work that it’s normal for multiple teams to work on the same epic simultaneously.

The second term is: Story.

Epics are normally made up of multiple stories. Each story is related to accomplishing the goal referenced in the Epic. Stories are usually small enough in scope that a single team can complete it without much, if any outside help. So, in our Carrack example, a possible story inside the Carrack epic might be: “Animate all the doors on the Carrack”.

The third term is fairly self explanatory: Task.

A Star Citizen Epic with 186 total tasks

Tasks are exactly what they sound like. They’re basically the smallest piece of work in this hierarchy. Stories often contain multiple tasks. Tasks are generally small enough that a single person is expected to complete them, however that’s not always the case. It’s fairly common to have a couple of people work together on some tasks, especially in the case of a new person being trained, or if a task is especially complex.

Epic Example

So now that we understand a bit of scrum vocabulary, let’s take a step back and see what Epics, Stories, and Tasks might look like in our example:

  • Epic: Create the Anvil Carrack
    • Story: Animate the doors on the Carrack
      • Task: Animate the top door (hangar)
      • Task: Animate the bottom door (ramp)
      • Task: Animate the MedBay door
      • Task: Animate the Engineering door
      • Task: Animate the bathroom door

It’s worth noting that organizing work in Epics doesn’t come naturally. The software development teams (devs, managers, and other stakeholders) generally have to spend some of their time in meetings every week discussing how to divide the work most effectively. Some organizations hire people specifically to help with some of this administrative work, but generally it’s handled by the team. Most teams will usually schedule a number of recurring meetings every week or so where they spend 30-60 minutes looking at future work and dividing it up into epics, stories, and tasks.

The next thing we’ll talk about are Story Points.

Part 2: What’s the story?

In order to understand HOW MUCH work needs to be done, we’ll give each story a numerical score that we call points. Hence the name “Story Points”. These points are a way to organize stories to understand how “big” or complicated each story is. It’s important to note the following:

Story points are generally NOT a measurement of TIME. They are a measurement of COMPLEXITY.

There are tons of practical, mathematical and philosophical reasons points are treated this way (some of which are discussed here) but we won’t even attempt to get into here, but as far as I’m aware, this is the general consensus. As you’ll see soon, you can use story points indirectly to guess how long a story or epic will take to complete, but it is in no way a guarantee or even a completely reliable measurement of time specifically.

Fibonacci Spiral

Fun Fact: Story points are usually only given in specific amounts that correspond to Fibonacci Numbers (1, 3, 5, 8, 13, 21)

Why? You can read about it online in more detail

Story points are generally assigned by the team doing the work because story points can vary based on the team. Remember, these points are a measurement of COMPLEXITY, not time, and complexity can be relative to the team performing the work. For example, a team of new or mid-level software engineers might look at a story and give it a score of 5 points. If you present that same story to a team made up entirely of your most senior software engineers, they might only consider the same story to be a 2 or 3 point story, depending on the work to be done.

Part 3: Time is on my side

Now that we know what story points are, lets have a team meeting and see how our team decides to assign points to the work we were assigned. In this case, we’re assuming that our team was assigned the work to animate all the doors on the Carrack:

  • Story: Animate the doors on the Carrack (5 points)
    • Task: Animate the top door (hangar)
    • Task: Animate the bottom door (ramp)
    • Task: Animate the MedBay door
    • Task: Animate the Engineering door
    • Task: Animate the bathroom door

Awesome! Our team has determined that our animation story is worth 5 points. But what’s the practical implication of those 5 points?

To recap, we now know that we’re one of a number of teams chosen to work on an Epic for creating the Carrack. Our team’s portion of this big effort is to complete the Story: “Animate the doors on the Carrack”. We’ve decided that this Story is worth 5 points of work, and we’ve divided it up into 5 individual Tasks.

Now that we have a solid understanding of WHAT needs to be done, let’s discuss HOW we’re going to do it.

Part 4: I know how to do it!

We’ve established WHAT needs to be done, but how do we go about doing it? Now we need to learn about Sprints and Velocity.

Sprints

Sprints are fairly simple to understand. A sprint is just a unit of time. Working on software is very similar to working on an art project in many ways. Just as artists sometimes have difficulty declaring that their latest piece of work is finally complete and ready for debut, software teams often have trouble declaring their work finished and ready for release. One way to combat this very human behavior is to force the development team to work in chunks of time with very specific end dates called sprints.

Sprints generally last about two weeks or so. The team decides to limit all their work to only the things they can commit to accomplishing in the next sprint. That way, if they commit to being done with whatever they decide to work on, they’re much less likely to have things drag out forever since they have a concrete deadline. Using moves the focus of the team away from the specific feature and more towards whatever the current task at hand is. It also forces the team to think more clearly and intelligently about how they divide up and segment their work.

Velocity

Under this paradigm, as a team goes about their daily routine of working on software, they follow a pretty simple pattern:

  • Receive story assignments
  • Assign points to those stories
  • Organize all the stories by priority, most important stories first
  • Choose as many stories as they believe they can complete for the next sprint
  • Formally place those stories into the sprint
  • Start the sprint and try to finish their chosen work by the end of the sprint

This is a continual process. Over time, the team will start to discover what their Velocity is. That’s basically the average number of story points the team is able to complete in one sprint’s worth of time. This is the “magic” piece of information you need to understand how the timeline for features is estimated. It’s such an integral part of scheduling that I think it’s worth stating again:

THIS IS HOW THE TARGET DATES FOR THE ROADMAP ARE DERIVED

Star Citizen Roadmap – Early 2020

People like Chris Roberts, Todd Papy, and the rest of the project management team sit down in high level planning meetings and look at all the development related Epics and Stories for the ENTIRE COMPANY and essentially do the following:

  • Look at ALL the work that needs to be done for the year
  • Count how many total points of work that is
  • Figure out how many points worth of work can be done in the next quarter
  • Organize the work in a way so that as many things as possible can be completed by the end of the next quarter
  • While organizing the work, keeping in mind what pieces of work are dependent on other pieces of work so as to be as efficient as possible.

I understand that might be a little abstract, so let’s go look at another example.

Planning Example

We’re planning for the next quarter. That’s 3 months of time. We’ll estimate that at 6 tw0-week sprints. So that’s six small chunks of development time before the next patch. Looking back at the last two quarters, it looks like all the teams combined have been able to complete, on average, 100 points worth of work per sprint. In other words, the VELOCITY for all the teams combined is 100 points per sprint. If we were to do the simple math, that means:

6 Sprints per quarter * 100 points per sprint = 600 points per quarter

So now we know, roughly speaking, that we can accomplish 600 points worth of work before the next patch goes out. Now we take a look at everything that needs to get done and try to find the most intelligent way to “spend” those 600 points. During this process, we will focus on getting the most important items complete while making sure we don’t choose items that will be left half-finished. We want to strike a balance between must-have, features, what will help speed up overall progress for the dev teams, and also keep in mind what will be the most enjoyable features to implement for the backers.

Once, that’s all been decided, it can then be laid out officially on the roadmap for everyone to see. All the teams then head off and start going through their list of items in order. But that’s the best case scenario. That doesn’t explain why things on the roadmap can move, so let’s talk about that next.

Part 5: Delays, AKA I can’t believe you’ve done this

So we have our master plan for the next quarter, but there are only so many people on each team, and they can only do so much in a given period of time. I am in NO WAY an advocate for “crunch time” game development. It’s just an excuse to maximize profitability at the expense of employees. People who work at NASA don’t crunch, and they do important work, so a video game isn’t nearly important enough to force people to work long hours at the expense of their health and family lives, even if it’s supposed to be for the sake of “the best damn space sim in the world”.

This means delays are inevitable, and delays in software development tend to happen for a few key reasons:

Personal Time

Remember, the developers are people too. People get sick or have kids or unfortunately, sometimes loved ones pass away. During the planning process, vacation time is normally taken into account when planning sprints, but unexpected events unfortunately negatively impact the schedule.

Development Difficulty

Generally speaking: software development can be very difficult. While development teams can make a best effort guess as to how difficult a task might be, the truth is: nobody knows how difficult it will be until they actually wade chest high into the code and start working on it.

A story that was originally given a score of 2 might actually be more like a 3 or a 5 after a developer spends an hour or so really getting into the problem they’re trying to solve or the feature they’re trying to implement. A new, previously unidentified aspect to the problem might be identified or entirely new problems might be discovered in the process of completing a complex task. That added complexity will often cause other things to get pushed back.

External Dependencies

Anyone who has worked in an office environment can relate to this class of problems: computer hardware problems, software problems, email problems, power outages, internet outages, floods, blizzards: basically all the other things that can go wrong and are not directly related to the development of the game.

At the end of the day, the work still needs to be completed, so the team tries their best to make due with the situation at hand. Afterwards, they sit down during regular review meetings and try to identify what they can learn from the situation and keep that in mind as they hopefully plan more accurately in the future.

Part 6: Summary

That was a ton of info, so let me try to summarize all of that:

  • Development teams work on epics, which are basically features.
  • Each epic is made up of multiple stories.
  • These stories each have a number of have individual tasks.
  • Each story is given a score (points) based on how difficult it is.
  • These scores are then indirectly used to guess how much work can be accomplished on Star Citizen in the next quarter.

These guesses can be made because the project managers keep track of the average number of points the teams can accomplish in a given amount of time. If there’s a delay for any reason, that delay changes the “algebra” used to calculate the schedule/roadmap, so features need to be shuffled around to maximize the  effort of all the teams.

Hopefully that helps to shed a bit of light on just one of the ways developers manage complex software projects. There are people who have entire careers centered around studying these concepts and using them to help companies make better software more quickly, so it’s entirely reasonable for the Star Citizen roadmap to look like a bit of chaos in a bottle, when viewed from an outside perspective.

 
%d bloggers like this: