Much of the “gating” terminology came out of the “Stage-Gate” process which is actually a registered trademark. And, yes I agree, it has somewhat of a “heavy” reputation. The pro of course is that it encourages a level of completeness or quality at interim steps along the way, of which you can’t pass through the “gate” until you’ve met an acceptance level other than “the code is written” <sic>. We all remember the projects that slipped 6 months in the last 6 days….. – we need to be tracking and monitoring along the way without creating too much overhead.

In Agile or iterative environments, there’s been a move toward “iteration (aka Sprint, Scrum) complete,” or “release candidate” (one that I’ve always liked, which implies that it is something that is functionally complete with a level of quality that COULD be shipped to someone and solve a problems for them) – from that, you can talk about “RC1, RC2, etc.” as functional complete milestones. These work best in a more agile, iterative approach.

If you are following a more traditional “waterfall,” then RC’s or iterations aren’t as good of a fit, since you won’t enter integrated testing until all of the code is written – you won’t have any “candidates to ship” until you’ve got most of the code written and tested. If you are more “waterfally,” then think about “checkpoint” rather than “gate.” I’ve also seen “milestone” used in traditional waterfall methods, and it is what we’ve taught for a while.

I think the critical players here to make the call are the PM, QA lead, Project Mgr and Dev Lead/Mgr. First question is agile vs. waterfall. Next question is “what determines “gates”? – ie, 25% / 50%, etc. code complete, Functional Test, Integration Test, Alpha, Beta – THEN call them something like “delivery milestones” or “delivery checkpoints” – regardless of what you end up calling it, Dev may still see it as a “gate,” but having the entire team’s buy-in to some level of QA/schedule integrity checking should get you past this hurdle.

Answered by John Milburn