Measurement and Metrics

Tutorials

MB SOLD OUT! Agile Release Planning, Metrics, and Retrospectives

Michael Mah, QSM Associates, Inc.

Mon, 06/03/2013 - 8:30am

How do you compare the productivity and quality you achieve with agile practices with that of traditional waterfall projects? Join Michael Mah to learn about both agile and waterfall metrics and how these metrics behave in real projects. Learn how to use your own data to move from sketches on a whiteboard to create agile project trends on productivity, time-to-market, and defect rates. Using recent, real-world case studies, Michael offers a practical, expert view of agile measurement, showing you these metrics in action on retrospectives and release estimation and planning.

TD Measurement and Metrics for Test Managers

Rick Craig, Software Quality Engineering

Tue, 06/04/2013 - 8:30am

To be most effective, test managers must develop and use metrics to help direct the testing effort and make informed recommendations about the software’s release readiness and associated risks. Because one important testing activity is to “measure” the quality of the software, test managers must measure the results of both the development and testing processes. Collecting, analyzing, and using metrics is complicated because many developers and testers are concerned that the metrics will be used against them.

TJ Software Metrics: Taking the Guesswork Out of Software Projects

Ed Weller, Integrated Productivity Solutions, LLC

Tue, 06/04/2013 - 8:30am

Why bother with measurement and metrics? If you never use the data you collect, this is a valid question—and the answer is “Don’t bother, it’s a waste of time.” In that case, you’ll manage with opinions, personalities, and guesses—or even worse, misconceptions and misunderstandings. Based on his more than forty years of software and systems development experience, Ed Weller describes reasons for measurement, key measures in both traditional and agile environments, decisions enabled by measurement, and lessons learned from successful—and not so successful—measurement programs.

Concurrent Sessions

BW6 Find Requirements Defects to Build Better Software

John Terzakis, Intel

Wed, 06/05/2013 - 2:15pm

Requirements defects are often the source of the majority of all software defects. Discovering and correcting a defect during testing is typically twenty-five times more expensive than correcting it during the requirements definition phase. Identifying and removing defects early in the software development lifecycle provides many benefits including reduced rework costs, less wasted effort, and greater team productivity. This translates into software projects that deliver the committed functionality on schedule, within budget, and with higher levels of customer satisfaction.

AW5 Agile Redefines Global Economics: What Recent Data Reveals

Michael Mah, QSM Associates, Inc.

Wed, 06/05/2013 - 2:15pm

Kent Beck, inventor of eXtreme Programming, defined agile success as delivering more useful functionality with fewer defects. Against that definition, early research revealed mixed success. Many organizations did not know how to measure and thus could not have “fact-based” conversations about productivity and cost. Some teams achieved faster delivery, but quality did not improve. Others found both. What factors made the difference? New benchmark analysis by QSM Associates reveals the latest productivity, time-to-market, quality, and cost patterns.

AW11 Agile and CMMI: Yes, They Can Work Together

Ed Weller, Integrated Productivity Solutions, LLC

Wed, 06/05/2013 - 3:45pm

There is a common misconception that agile and CMMI cannot work together. CMMI is viewed as a documentation heavy, slow, process-driven model—the polar opposite of agile principles. The cost of documentation for an appraisal is viewed as another drawback. Join Ed Weller to see why a large organization chose to use the practices in the CMMI to complement agile, and a formal appraisal to improve and evaluate their performance.

BT4 Non-Pathological Software Metrics

Stephen Frein, Comcast

Thu, 06/06/2013 - 10:15am

As semi-scientific software professionals, we like the idea of measuring our work. In some cases, our bosses like the idea much more than we do. Yet, meaningful software development metrics are notoriously challenging to define, and many people have given up trying because metrics often incentivize pathological behaviors. Since you get what you measure, most metrics lead development teams to optimize numeric proxies for success rather than the goals these proxies were intended to represent.