I don't want to argue the talk - he actually does a great job in my opinion of making the case for a more empirical process of prediction. However, he sort of throws out a false message in that he poses the question of project completion forecasting at the beginning then focuses on cycle time without ever answering the original question. From my own Kanban knowledge, I can tell you that there are some steps left out.
Throughput
What you actually want to measure is throughput. How many items are done in a given period of time. If you are practicing Scrum, that period will often be a Sprint, but it doesn't have to be. It can be a month or week or quarter. So, for your case, if you completed 6 items per sprint and have 56 (assuming that total number holds) you will finish in about 10 sprints. Of course, that number might just be an average, so let's say you complete between 5 and 7, then your pessimistic forecast would be 12 sprints and your optimistic would be 8 sprints. You may notice that we've just described a burn-up chart using story count instead of story points.
Note: This is the answer to your question, the rest is just supporting info.
Cycle Time
So what is cycle time for? When he was showing the scatter plot diagrams, you may have noticed that the "incredible predictable" scrum team's 50th percentile line was at 13 days. Now, since a lot of teams have a 2-week sprint, this should raise an interesting observation - namely, that they were completing very few backlog items within their sprint and a lot of work was spilling over. In his example, by being mindful, the team got their 85th down to 13 days, which is nice, but that still means that only items started on day 1 of the Sprint could ever finish in the sprint. So, next thing to do would be to look at why the cycle time is that long, and through this sort of introspection, we can reduce it further.
Your Dataset
You are breaking up cycle time into sprints - don't. Look at scatter plots across sprints unless there is a specific thing you're trying to learn by doing it. Taking the average of your 85th each sprint will often get you a very different number than the 85th of all items across those 4 sprint and can lead you astray.
Little's Law
So, why can't we just take our 85th cycle time and multiply it by the number of backlog items for a pretty good estimate? Because of WIP. He mentioned Little's Law, which says that:
Avg Cycle Time = Avg WIP / Avg Throughput
Which tells us that the average cycle time will always be lowest when WIP is 1. For some teams, this is great, but it focuses on responsiveness. You want your Fire Department to never exceed a WIP of 1 so they put your house out as fast as possible. Most of us aren't in a job that focuses on responsiveness first though. We usually want throughput, so we want to refactor that equation to look like this:
Avg Throughput = Avg WIP / Avg Cycle Time
In real situations, this creates a bell curve showing that most teams, for their highest throughput, should have a WIP greater than one but that after a point the throughput will shrink because of too much split focus. How do we find that point? Mostly by experimenting, but that ideal for most software teams sits around 2 - 4.
The Sprint
And then there is the Sprint. Closing everything up at the end of a sprint actually disrupts flow. Your throughput will almost always be lower with sprints than without because you artificially force a wrap-up every few weeks. This isn't necessarily bad. That wrap-up gets us stable product increments that make it easy to absorb feedback, pivot, and drop items out of our backlog we've discovered we don't need. For most software teams, the payoff for this more than makes up for the throughput ding.
I know that went way past your question, but I'm afraid your question as it was phrased was largely unanswerable. I hope this helps. Definitely look more into Kanban metrics, they are awesome, even for Scrum teams.
