QSM's recent webinar, How a Collaborative Estimation Process Produces Realistic Estimates Fast, presented by Laura Zuber, sparked a lively Q&A session from our audience. Here are the highlights:

Q: How do I know which template to use when creating a new estimate in SLIM-WebServices?

A: That’s a good question. Your back office administrator configures templates to map to your software development lifecycle, your standard processes and different project types. The back office person can provide detailed descriptions and key information that are viewable from the Feasibility Wizard so you know which one to select.

Q: What makes a project assessed as conservative or risky?

In a recent, highly-discussed article for Dr. Dobb's, QSM's Carol Dekkers asks a tough question: why are we so woefully poor at estimating software projects? It's a tough pill to swallow considering software developers are among the smartest people on the planet, often boasting advanced degrees in mathematics, engineering, or computer science. Yet study upon study cites that less than one-third of projects are delivered on time or on budget. The problem of software project estimation is not straightforward. To get the heart of the issue, Carol Dekkers takes us through the five top misperceptions about software estimating, and what we can do to address them.

Read the full article on Dr. Dobb's!

We know agile works well for small teams and small projects, but monster enterprise projects often require greater capabilities than a small team can provide. So why not scale up agile teams to maintain the cost and efficiency benefits of the agile process while accessing the necessary manpower to pursue complex global projects? On the surface, it makes sense, but what if agile only works when teams and projects stay relatively small? That's the question most CIOs want answered before investing scarce time, energy, or resources chasing the big agile paradigm. In this article recently published on Agile Connection, QSM's Larry Putnam, Jr. turns to cold hard data from completed projects in the QSM database to determine whether big agile is "enterprise savior or oxymoron."

Read the full article!

Can advances in data-driven estimation turn software project failure into a distant memory? Well, if learning from experience is the key to success, imagine what you could do with real-time access to three decades of research, thousands of projects and more than 600 industry trends. In this article, originally published on Projects at Work, QSM's Larry Putnam, Jr. identifies key benefits of employing estimation best practices for project success.

As Co-CEO for QSM, Larry Putnam, Jr.'s has more than 25 years of experience in software measurement, estimating and project control. He joined QSM in 1987 and has worked in every aspect of the business, including business development, customer support, professional services and now executive management.

Read the full article!

Is your agile team’s velocity constant from sprint to sprint? No? That’s not a surprise. Many teams assume that their velocity will be constant. In this article, the third in a series recently published on Projectmanagement.com, QSM's Andy Berner explains why that’s not the right expectation--and how that affects how you use this metric.

Andy Berner is a software engineer and methodologist. He came to QSM in 2012 after over 25 years in both large and small software organizations, including, among others, EDS (now HP), Rational Software and IBM. Based on his experience in almost every role in software development, Andy has consulted with numerous organizations on using software development methods and tools to improve productivity and quality.

Read the full article!

In our recent webinar, Function Point Analysis Over the Years, presented by Don Beckett, we received some great questions from our audience. Here are the highlights from the Q&A:

Q: The advice in recent years is to break large projects down into smaller ones to make them more likely to "succeed" by whatever measure. Is the advice now to make projects bigger?

A: I don't know if it's advice, but the data seemed to indicate that there is a benefit to grouping projects by larger size than the projects that are 50 or 100 function points. So I would say, where it's possible, where they can be grouped together, it would be a good idea.

Q: Why do you use the PI (Productivity Index) as opposed to the industry standard hours per function point or function points per person month?

A: Well hours per function point and function points per person month are ratios that take the ratio between effort and size and what we have found is that the schedule has a huge impact on how productive a project can be. The PI incorporates three major things: the size of the project, the amount of effort leveraged against it, and the time required to do it, so in a sense, it accounts for schedule, which function points per person month does not do. So that's why we use it.

Q: How do we convert a project from SLOC to function points to find the PI for a specific project?

In an agile project, the backlog (the prioritized set of requirements) is the main input to iteration planning. For an agile project to progress smoothly, the backlog must be groomed and ready for each sprint. That work must be included in your project plan. In this article, the second in a series recently published on Projectmanagement.com, QSM's Andy Berner gives you five points to consider when planning that work.

Andy Berner is a software engineer and methodologist. He came to QSM in 2012 after over 25 years in both large and small software organizations, including, among others, EDS (now HP), Rational Software and IBM. Based on his experience in almost every role in software development, Andy has consulted with numerous organizations on using software development methods and tools to improve productivity and quality.

Read the full article!