Aaron Jeutter, a participant in the QSM Agile Round Table from Rockwell Automation, presents the technique of “Big Rock Sizing.” This technique is used at Rockwell Automation for early sizing and estimating based on high level requirements that will be refined using agile techniques as the work progresses.
In this Projects at Work article, Jay Daniel explains how agile software development can benefit from a fundamental development practice like sizing.
In this article for GCN, QSM's Joe Madden explains how the five core metrics of software estimation make a powerful tool that can be used at each phase of the software acquisition life cycle to help government IT program managers make more objective, quantitative decisions.
Industry expert Phillip G. Armour highlights the importance of the QSM Software Almanac: 2014 Research Edition in his recent article for Communications of the ACM.
This paper by QSM Consultant Carol Dekkers seeks to marry International Function Point Users Group (IFPUG) definitions with equivalent concepts in agile/iterative processes so as to create a basis for consistent comparison.
In a recent article for Projects at Work, QSM's Don Beckett identifies seven principles, based on comprehensive studies, that leaders must support and uphold to help create an environment in which projects can succeed. Ignoring them practically guarantees failure.
How can we estimate a project in advance, while still maintaining the ability to manage the backlog in an Agile manner? In this article, Andy Berner answers that question, compares release-level estimation to the techniques used for iteration estimation, and gives some pointers on getting started with release estimation in an Agile environment.
How can I possibly estimate the size of something I’ve never done before?
The modern computing environment poses many challenges. Foremost among them is addressing totally new technologies. Trying to figure out how “big” computer programs are has challenged software engineering since its inception and is further complicated by the aforementioned dynamic nature of technology.
What will happen to your date-dependent software when the year rolls from 1999 to 2000?
There is no doubt that the millennium date change problem is huge. Thus according to Gartner Group’s strategic planning assumptions:
This article discusses multiple applications based on only four measured metrics: size (function), effort, time, and defect rate. From these metrics, we can manage a project.