Another cause of long gaps between kickoff and coding: Are the product managers and engineers on the same page about requirement details?

If requirements aren’t thoroughly researched and thought through, this will cause a lot of thrash. No one wants to start coding if requirements are constantly changing. So make sure your product managers have a standardized template, and hold them accountable for anything missed that was obvious. Furthermore, the engineering organization cannot have every detail spelled out before they start. This is quite literally waterfall methodology, and will grind your velocity to a halt.

At the end of the day, a pact between product and engineering is the most important thing, as well as working closely together when coding starts. We are in an agile world, after all.

And this leads us to our last area, what the heck is in the next engineering sprint anyway?

It really is hard to overstate how important momentum is for engineers. Context switching will be the death of your projects. So keep them out of meetings, don’t tap them on the shoulder when they have their headphones on, and keep the queue focused. How many points per sprint is the team spending on features, vs bugs, vs user requests, vs tech debt? There is no standard ratio, and the balance is highly dependent on the goals of the company. But unless there are some extenuating circumstances, achieving an 80%+ focus on feature development is a strong goal.

Some things that can help:

Creating support teams (tier 1, tier 2) to deflect non-feature related work from sprints. This also greatly helps your SLAs. Learning to say no, and letting fires burn Better test coverage, because poor test coverage leads to more… wait for it… BUGS. Well thought through requirements, to avoid review hell.

The result will be leaner sprints, focused engineers, and more feature development. And higher organizational velocity. Velocity in building products is critical to scaling your business and beating your competitors. Learn more about Blitzscaling from Reid Hoffman and Chris Yeh.

If you take the time to examine and improve these three areas above, I can guarantee that you will see drastic improvement to your project velocity. And that’s really what we’re all after anyway.