Diagnosing Your Chronically Late Software Releases

That moment when the hammer comes down, and you realize – you didn’t hit your release goal.

We’ve all been there, and it’s not a great feeling. It’s even worse if you feel it over… and over… and over. If that sounds familiar, you may have chronic late-release syndrome. Not only does it irk your bosses and users, it’s a recipe for a disjointed, disenfranchised engineering team.

The solution is simple: just work harder!

If only it were that easy. There is no stick pointy enough, no carrot sweet enough, to fix tardy releases with longer hours. And putting pressure on an already-deflated development team is sure to do wonders for your culture.

There’s rarely a single cure to the problem of late releases, because there’s rarely a single cause. Assuming your team is generally competent and you’re not actively trying to sabotage each other (even if it seems that way sometimes), it’s likely a case of poor release hygiene. The only fix: living and breathing healthy habits like open communication, reduced silos, and the right processes to streamline it all. So what are the right processes, and how to do you bake them into your DNA?

Define done

If your issues aren’t quite making it over the finish line, your team may be misaligned on the definition of done. Until you have defined it in a concrete way, you won’t be able to accurately plan for how long “done” will take. To put it simply, your estimates will be off from the beginning.

To a user, a feature is “done” when they can use it – when it’s in their hands bringing them value. To a programmer, “done” may be when a feature has been passed over to the QA team. See the problem here? The former version of “done” involved a lot more work. There was testing, deployment to staging, refactoring, more testing, deployment to production, release notes, and documentation.

Have a conversation with your development team, product and project manager, and any other project stakeholders to come to an agreed-upon and explicit definition of done.

Here’s an example of a very simple definition of done, which can be added to a GitHub issue template.

• Code done; code review complete
• Tested and approved by product owners
• Documented where necessary

You can go a step further and define “acceptance criteria,” which ensure a feature isn’t just done, but done well. These are typically unique to each issue, and should be captured before an issue makes its way into a Sprint. (In ZenHub, we use GitHub Milestones in place of Sprints.)

Acceptance criteria should be written in terms your customer would use. What exactly are you trying to accomplish with this feature? What value will the user get when it’s shipped? Don’t talk about how that value will be accomplished – that’s to be determined during the development process – but why.

Get better at bad guesses

If you’re already using estimates, great! But who’s making those estimates? The development team, or someone else?

If the answer is “someone else,” that’s the wrong answer.

Only the development team should be estimating the software they’re building. In an agile project, we don’t know much about complexity when we begin a feature. However, if we’re using story point estimates and sizing tasks relatively to each other, we’ll be able to gauge how complex a feature is compared to our other tasks. Agile projects typically use story points because they’re fast, easy, and remind everyone that estimates are not a deadline, but a guess.

Using time estimates too early is a surefire way to over-commit. After all, time estimates refer to actual productivity of real people. A “complex” task is complex for both Sarah and Sam, but that complex task could take Sam twice as long as Sarah.

Estimates are not, and should never be treated as, a target deadline.

Once you’ve gotten in the habit of relative estimates, ZenHub’s Velocity Charts become a powerful tool to help you understand your actual speed of work. You’ll be able to set goals that are both ambitious and informed by reality.

Issues are cheap but valuable

GitHub issues are cheap, but their value shouldn’t be underestimated. Often times a late-release problem can be attributed to poor issue management.

First, take stock of your backlog. When an issue lands in the lap of a software developer, does it read like a fortune cookie? Or is it well-defined, estimated, and explained in relation to user benefit?

Poorly defined issues mean that a developer will have to spend their time defining that issue (and their definition may be different than yours). Keep issues as granular as possible, and use Epics to break meaty goals into manageable bites. Make product backlog refinement a regular part of your sprints, and be rewarded with a clearer path to success.

A note on scope creep

In a similar vein, scope creep is a threat to any project, whether you’re building software or something else. Scope creep (or requirement creep) is a term used to describe the situation where a project increases in size beyond the originally defined scope.

There are times when scope creep is good, and other times when scope creep can be incredibly harmful to your release progress. For example, once a Milestone has been defined and started, the scope of the Milestone must remain unchanged. Scope creep inside of a Milestone is no good. When looking at a product as a whole however, scope creep outside of a Milestone is actually a good thing, and it’s how you build an iterative product while keeping the end user in mind.

Burndown Charts are a handy visual tool for bringing scope creep to life. If more issues are added in the middle of a Milestone, the impact is unavoidable when visualized in this way. At a glance, you can understand whether you are still on track to meet your release goal.

If you can internalize these rules, you’ll be on your way to consistently hitting your releases on time. Remember, it’s about more than just knowing where the problems lie; it’s also about making sure that your team knows, too, and that everyone is on the same page to address the potential downfalls.

If you’re new to ZenHub, download it for free and take advantage of the valuable reporting features mentioned above.

Thanks for reading! Any questions about ZenHub? We’d be more than happy to help on Twitter @ZenHubHQ or email us directly.