Conference Presentations

BSE Testing To Estimate or Not to Estimate, is that the Question?
Slideshow

Wondering what NoEstimates means in practice, or why you would want to move toward NoEstimates? Perhaps you’ve heard the buzz or read Vasco Duarte’s book. Maybe you simply want to understand how you can spend less time estimating and more time delivering working software...

Matthew Phillip
The Impossibility of Estimating Software The Impossibility of Estimating Software

Estimating software schedules must be an art, not a science. With so many techniques published on the subject, why is it so difficult? It has to do with the human element and past project knowledge.

Monetization 2.0: The Evolution of Software Licensing

The cloud and the rapid migration to mobile devices and the Internet of Things have made traditional software licensing schemes obsolete. Omkar describes new software monetization based on business, pricing models, and usage.

Omkarnath Munipalle's picture Omkarnath Munipalle
Larry Putnam Jr. discusses software estimation and project planning From Proposal to Project: An Interview with Larry Putnam Jr.
Video

Larry Putnam Jr., co-chief executive officer at QSM, sits down to talk about the importance of the proposal when executing a successful project, five key questions that should be answered before any project starts, and how software estimation ties into the proposal process.

Can Test Estimation Be à la Carte?

In this installment of FAQ, Rob Sabourin discusses the benefits of providing stakeholders a "menu" of past projects to help better estimate their current project's testing needs.

Robert Sabourin's picture Robert Sabourin
Piece By Piece: Test Estimation and Planning in Agile Teams

The iterative agile methodology provides a clearer vision, smaller time scale, and closer planning horizon. The authors look at approaches to estimation and planning, from product backlog grooming to task-estimating tables and more.

Estimating in Software Development: No Silver Bullets Allowed
Slideshow

What do poker, Greek oracles, an Italian mathematician from the Middle Ages, and the path of hurricanes have in common? Given the title of this presentation, chances are it has something to do with estimation, and you'll have to attend this session to get the full connection. Kent McDonald explores the challenges and realities of trying to estimate software-related knowledge work-analysis, testing, development, and the entire project effort. A major challenge is that there are no guaranteed ways to arrive at perfectly accurate estimates, which not surprisingly is why they are called estimates. Kent introduces and gives you a chance to practice quick and practical estimating techniques that will work in different situations-guesstimating, break it down and add it up, and planning poker.

Kent McDonald, Knowledge Bridge Partners
Lessons Learned from Forty-five Years of Software Measurement
Slideshow

Counting is easy. However, what makes measurement really valuable-and really hard to get right-is knowing what to count and what to do with the results. If your organization is mostly tracking resource usage, costs, and schedule data, it is making a big mistake. What about the users? The customers? The overall business strategy? Sharing the lessons he has learned from fighting-and surviving-many software measurement battles, Ed Weller offers a step-by-step approach for implementing a practical and valuable metrics program. After understanding what measures are most important to the business strategy and all stakeholders, the next step is to decide what data supports those measures and how to capture it. With data in hand, you can create simple and informative ways to make the resulting metrics visible and easy to digest. The biggest challenges-avoidance, disbelief, and rationalization-come next.

Edward Weller, Integrated Productivity Solutions, LLC
Does anyone have estimation metrics for configuration management and data management?

I do a lot of estimations for projects involving configuration management and data management. One of the requirements these days is that you make estimates based on historical actuals or metrics derived from same.

Unfortunately, I have yet to find a highly correlatable metric that will definitively provide an estimate that will result in a fairly accurate bid (when compared to the conclusion of execution). I recognize that such things are highly variable, and a lot of items can impact getting a good metric.

I would be interested in knowing if anyone out there has a metric that can be shared in this public forum that has a high degree of correlation to actual hours experienced. Some of the metrics I've seen are:

% of software design/code/integration hours (% of DCI)
hours/month
hours/release
hours/change request
% of Lines of Code

none of which - to my satisfaction - yeild a definitive answer.

skershaw
Building Highly Productive Teams Using a Commitment-to-Progress Ratio: Work Committed vs. Done

This article explains methods to build a team that will embrace "required work" and deliver robust software in a predictable fashion. It proposes a measure that helps calculate the throughput of an agile team by comparing work committed to work actually done.

Aleksander Brancewicz's picture Aleksander Brancewicz

Pages

CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.