Time to Create Branching Scenarios

To estimate the time to create branching scenarios, consider the size, complexity, multimedia, programming, and tools.

How do you estimate the required time to create branching scenarios? It’s tricky to estimate, even for me, because branching scenarios can vary widely in complexity. In order to figure it out, we have to consider several factors: the overall size of the scenario, the complexity of the branching structure, the amount of multimedia, the difficulty of any triggers or programming, and the tools used.

Track your own time

Overall, the best way to estimate your time to create branching scenarios is to actually do it and track your time. I have estimates because I have tracked my own past projects. While I’m going to share some of those actual numbers as examples, I suspect that my times may not be accurate for people with less experience. My Storyline development times aren’t especially speedy, but I do tend to write branching scenarios quickly. If you’re doing it for the first time, expect it to take longer.

Time to Create Branching Scenarios

Size

One of the biggest considerations is the size of the scenario. While we often think about training and elearning in terms of “seat time,” that’s not a good measure for branching scenarios.

Number of slides or passages

Example 1: Last year, I built a branching project that was quick, at least for the learners. It only took 10 minutes for the learners to complete. However, the final version required 75 slides. This scenario had a lot of rapid-fire decisions with immediate feedback, similar to one of Clark Aldrich’s Short Sims. The image below shows the structure as of the alpha version, which had only 52 passages.

Branching scenario with color-coded passages. A series of blue-tagged passages is aligned at the top, showing the decisions required.
Larger branching scenario project

Example 2: On the other hand, branching scenarios can sometimes be very small. For this project, I wrote scripts for videos with decisions. We had a limited number of videos we could record within the scope, so I had to keep the overall number of passages (and therefore videos) small. This one only has 12 passages and 1675 words.

Branching scenario with 12 passages
Interactive video branching scenario

Example 3: The chat simulation I built earlier this year is also about 50 passages, comparable to the large branching scenario.

Chat simulation structure

Word count

While the number of slides or passages is important, consider the total word count too.

Example 1: The larger scenario above only had about 2300 words as of the alpha version, and maybe closer to 2800 in the final version (Storyline doesn’t have a word count feature). Each passage or slide is very short, with very little text to read. It’s an average of 45 words per passage.

Example 2: The interactive video scenario project had few passages, but much more text per passage. That has 1675 words in 12 passages, or an average of 140 words per passage.

Example 3: Since the chat simulation includes only short text messages, it’s only 900 words in 50 passages. That’s only 18 words per passage. The total is less than half the total word count for the same number of passages as the large scenario.

Time to plan and write

As noted above, these are my actual examples; your time to write may be different.

Example 1: The large branching scenario with 52 passages and 2300 words took 13 hours for the analysis, design, and writing. That was inflated somewhat by multiple rounds of revision on the design document and overall concept. The actual writing took under 5 hours.

Example 2: The interactive video scenario with 12 passages and 1675 words took 3.5 hours to write.

Example 3: The chat simulation with 50 passages and 900 words took about 90 minutes to write.

Reviewing my previous projects, I can now project that I write about 400-500 words per hour for branching scenarios.

Complexity of the structure

Some branching structures are extremely complex, with lots of paths crossing and intersecting, very deep paths, or numerous endings. That’s harder to estimate, but you can at least generally think about the kind of complexity needed when you scope a project.

In the image of the larger branching scenario project above, you can see the passages marked in blue at the top. Each of those is a decision for that scenario. Most decisions have options that are good (green), OK (yellow), or bad (red). A few passages have options for additional information and support, marked in purple.

However, the overall branching structure is fairly simple. None of the branches are very deep vertically, and they all come back to the same decisions in blue at the top. This scenario has a branch and bottleneck structure with numerous bottlenecks. That reduces the overall complexity, plus it makes revisions easier later.

That heavy use of bottlenecks ended up being really helpful for that project. As I mentioned earlier, that scenario ended up with 70 slides, even though the alpha version only had 52 slides. During the review process, numerous changes were requested. While some were easy (more intro and closing slides), several changes required adjustments in the structure and what path the learners followed. The bottlenecks simplified the revisions because the decisions were generally independent.

More complex structures may take more time to write, plus they take more time to build and test. Simpler structures take less time.

If you want to learn more about how to reduce that time, read my tips for managing the complexity of branching scenarios.

Multimedia

How much multimedia do you use in your branching scenario? Cathy Moore has discussed the cost of eye candy in scenarios.

The cost of eye candy is often a too-easy activity. When I’m cranky, I’d say a lot of elearning suffers from this. It’s strong for the eyes but weak for the brain.

What would happen if we invested less in eye candy and more in designing deep challenges?

Check out her post for a comparison of two similar branching practice activities. One has lots of images but only 6 decisions. The other scenario is basically text based, with only a single photo, but many decisions. The development time was obviously much lower for the second one. For the same amount of total time, she spent much more writing the actual decisions, rather than building multimedia.

That’s not to say that sometimes more multimedia isn’t valuable. The interactive video scenario in example 2 dealt with communication skills. Participants needed to recognize cues in body language and tone of voice. I’ve also done scenarios where analyzing the environment and context were important, and therefore photos or videos made sense.

Audio, images, and video are worth using when they help meet the learning objectives. Just be sure to include that development in your time estimates.

Triggers or programming

If you need to provide customized feedback based on the choices made or show ongoing progress through meters, the time to create branching scenarios goes up.

How much it increases depends on the tool you’re using, the skill of the developer, and the complexity of the programming required.

Tools

The tools you use to both write and develop your branching scenarios affect the total time to create them. I use different tools for different projects, depending on the need and the scope.

Example 1: I planned and wrote the large branching scenario in Twine. After the alpha version, I used Storyline for the beta and final versions. The scenario has text and images but no audio, video, or complex triggers. That took me 30 hours of development time plus 7 hours of revisions. In general, it takes me 20-30 minutes to build one slide in Storyline for these sorts of branching projects.

Example 2: Because this was an interactive video scenario, developed required actors, a videographer, a makeup artist, etc. This was a half day shoot for the video with two actors, plus editing time. The final product was built in Storyline by another developer, so I don’t have a time estimate. It’s safe to assume this was the most expensive scenario to produce.

Example 3: I used Twine to build the chat simulation quickly. The entire project took 2 hours from start to finish, with only about 30 minutes of development time.

If you write in a tool designed for linear content, such as Word, your time to write will probably be higher than if you use Twine for at least the initial draft.

Total time

What does that mean for total time in my examples?

Example 1: The large scenario took about 60 hours total, including analysis, design, writing, development, revisions, and project management.

Example 2: Unfortunately, I don’t know the actual total time on this project. It was likely 60-80 hours, considering everyone involved in the process.

Example 3: The chat simulation was only 2 hours total. However, since that was a project for my blog and not an actual client, I’d assume a few more hours for planning and revision as an actual project. Without tweaking the visuals much, it would be about 5 hours total; with more CSS styling work it could be closer to 10 hours.

Of course, this is why it’s so hard to estimate the time to create branching scenarios. It could be 2 hours; it could be over 100 for a longer scenario with lots of complexity. But, you can use these considerations in scoping your projects and looking for ways to reduce the required time.

Branching scenarios webinar

If you’d like to learn more about how to streamline branching scenario planning and design, I’m giving a webinar on Thursday, October 14, 2021 at 12:00 PM EDT. I’ll be sharing a ton of tips on how to save time creating branching scenarios, including getting what you need from SMEs and using different branching patterns. You can register for free here.

1 thought on “Time to Create Branching Scenarios

Leave a Reply