While Agile methodologies have made tremendous advances in programming circles, build and release management teams have traditionally shied away from a “full agile” approach. In informal polling of Build Engineers, I found only one team outside of my own that ran an Agile shop; while there are many out there who do, there are tender points that need special consideration.

A working definition of “practice” is: A practice is a common and adaptive approach for doing something with a specific purpose in mind. When “being” agile and applying a practice we are focused on value-added not the means.

The agile methodology, like many concepts, is based on an “ideal” setting or environment. In the agile domain this usually constitutes a 100% co-located team of generalists who have unfettered access to the primary business stakeholder. Working in an ideal environment makes sense when you are describing theory, but organizations can find this perfect environment unachievable due to basic business constraints: resource skill sets, location, and time allocation. These constraints present barriers to agile adoption, can hinder productivity, cause frustration amongst the team, and can lead to project failure.

The product backlog is the ultimate resource to making sure that your project sees the light of day, and of the highest quality possible. That is, as long as your backlog is given the attention it deserves, and needs. In this article we help you keep your backlog groomed to perfection.