"Why has it been a while and X still isn't patched?" (A software engineer's perspective)

From a software engineering perspective, here's why things RIOT promises (as well as changes we ask for) don't get changed immediately and often take a while, based on my best guess, if RIOT uses an agile development process. Hopefully, this can explain three scenarios:

1. Why balance changes to existing problems sometimes come late.
2. Why balance changes to emerging problems often take a couple patches.
3. Why promises from RIOT to do X take time.

As everyone already knows, RIOT operates on a two-week patch cadence. This cadence is called a "sprint" in the software engineering world. Each sprint, the development team (of which there are many, most likely divided between various teams, such as items, skins, champion balance, etc.) "commits" to a set number of tasks for the sprint. These tasks are called "stories."

A story represents a single piece of work from start to finish. One such story from the latest sprint, for example, could have been, "change the gold balance of minions to favour cannon minions." From there, a team member would pick up a single story to work on from the list of stories they've committed to for the sprint. One by one, as they finish the story they've grabbed, they'd pick up new stories, hopefully completing all the stories in a sprint they've committed to. At the end of the sprint, they cut a release, and that release becomes the patch. Stories collectively live in a backlog of work with all kinds of things RIOT wants to do in the future (meaning, there could already be stories for specific changes for preseason/next season waiting for their sprint to arrive).

(For visual reference, stories are tracked on a virtual board that looks like some variation of this. Every segment is a story, and as devs work on them, they drag and drop them along the board until they hit the "Done" column. This is for a single sprint; the backlog contains the whole "pool" of other stories.)

http://i.stack.imgur.com/u2bhp.png

This brings us to problem #1.

Balance changes to existing problems sometimes come late.

There are two main reasons this happens all the time.

As I said, each story is a single unit of work. However, first, stories need to be organized into priority order. For example, a story for nerfing Yasuo may be considered a higher priority than one for fixing Frostblade Irelia's skin, so the Yasuo story may be committed to in a more immediate sprint, and the skin change story would come at a later sprint (read: later patch).

The other reason this happens is because, just like all of us, sometimes devs bite off more than they can chew for a sprint. Sometimes there are stories that the team commits to for a sprint that they simply just don't finish in time for the end of the sprint. (Nerfing Yasuo simply just took too much work for one sprint.) These stories then get carried on to the next sprint and continue to be worked on. This does not, however, stop the sprint cycle, and in the software development world, there is no extending a sprint. Therefore, these changes simply do not make the cut for the patch and therefore will be in the following patch (or whatever patch the work is finished on).

Problem #2, which is closely related to the above.

Balance changes to emerging problems often take a couple patches.

As stated, sprints, as well as stories committed to for that sprint, do not change. Here's an easy example of a potential result:

• Ezreal synergizes way too well with a new item on day 3 of a new sprint, and we just realized it.
• A new story to nerf Ezreal is made.
• That story cannot be committed to until the next sprint (this one has already been committed to with its stories).
• This sprint ends, a patch is released. A new sprint begins, containing the story to fix Ezreal.
• Ezreal gets nerfed this sprint.
• The sprint ends, and Ezreal gets patched with the end of the sprint, over three weeks after the initial report of the problem.

Yes, three weeks (two patches) to nerf Ezreal. Therefore, often times, things just don't line up from a timeline perspective optimally.

Lastly, problem #3.

Promises from RIOT to do X take time.

RIOT says, "We plan to rework Yorick." They make a story to rework Yorick. That story gets placed in the backlog with the other stories that are not being worked on this sprint. The managers arrange that backlog to be in priority order, leaving poor Yorick 2 years deep in the backlog. Yes, a story exists, and yes, he will (did) get reworked, but before his story could be committed to, the team had to whittle down the backlog until they finally hit his story, the ordering of which was dictated by the managers (read: not the balance team).

This is an oversimplification of some things. You can imagine, though, how this process can sometimes lead to really, really big gameplay problems. A quick example, imagine that there were two stories committed to for a sprint, one that nerfs but buffs . However, the sprint ends before the developers finish the story to nerf Duskblade, but they did finish the story to buff Zed. The sprint ends, the patch ships, and oops, that's OP. (Maybe this is what caused 4.20 Warwick.)

That said, this process is overall incredibly efficient, and over time, as the teams realize exactly how much work they can do in a sprint, these events rarely happen. The process allows for a regular cycle, relatively fast reaction time (in the grand scheme of things), and definitive organization of tasks.