During a recent consulting engagement, a customer asked if the QSM defect discovery model applied to Agile projects.  Of course, the best (and only) way to determine this was empirically.  From our database we extracted a sample of business IT projects that had completed since 2013 that recorded pre-implementation defects.  81 of these projects were Agile and 354 did not specify Agile as their development methodology.  We created average trend lines for both datasets and they displayed very similar patterns that conformed to the QSM defect discovery model.  This allowed us to answer our customer’s question affirmatively.

Having a large project sample at hand and being curious, we decided to compare these metrics:

• Mean time to defect (which measures the average time a system runs defect-free in the first month after implementation)
• Average development time in months
• Staffing
• Cost/effort

In a nutshell, the Agile and non-Agile projects used very similar staff sizes.  The Agile projects completed sooner and expended slightly less effort.  Quality was where the two project sets differed significantly.  Pre-implementation, Agile projects recorded fewer defects than non-Agile ones.  However, post-implementation the non-Agile projects operated longer between discovering defects in production than did Agile projects.

If you were unable to attend our recent webinar, a replay is now available.

Agile methods have brought vast improvements to software development practices, but as with any process, still pose many implementation challenges. Estimating, planning, and tracking Agile projects is particularly difficult because the formality, consistency, and repeatability of Agile practices vary widely across organizations. In this PDU-approved webinar, Laura Zuber shows how macro level metrics gathered for completed projects and used as the basis of estimation and project control promote repeatability and predictability. Learn how SLIM-Suite tool’s customizable modeling parameters, such as Agile increment lines and sizing techniques, let you balance the needs of teams and the business.

Watch the replay!

Agile methods have brought vast improvements to software development practices, but as with any process, still pose many implementation challenges. Estimating, planning, and tracking Agile projects is particularly difficult because the formality, consistency, and repeatability of Agile practices vary widely across organizations. In this PDU-approved webinar presented Thursday August 13 at 1 PM EDT, Laura Zuber will show how macro level metrics gathered for completed projects and used as the basis of estimation and project control promote repeatability and predictability. Learn how SLIM-Suite tool’s customizable modeling parameters, such as Agile increment lines and sizing techniques, let you balance the needs of teams and the business.

Register now!

If you were unable to attend our recent webinar, a replay is now available.

In many agile and even non-agile development environments, the budget, team size, and schedule are fixed based on an organization’s predetermined targets. This leads many project managers to question how they should proceed with target negotiations and some even wonder if they should estimate at all. The problem is, without a reliable estimate, the amount of functionality promised within the time and money constraints could be difficult to achieve. This could cause the product delivery to be short on features, or late and over budget.

Join Keith Ciocco for this webinar as he demonstrates the role of scope-level estimation tools in evaluating if targets are reasonable and in determining how much functionality can be delivered. This crucial analysis helps set customer expectations and provides data-driven leverage for negotiations.

Watch the replay!

If you were unable to attend our recent webinar, "Perspective and Predictability in Agile Release Planning," a replay and slides are now available.

Whether you release on-demand or according to a regular schedule, being able to visualize how many sprints it will take provides instant feedback so you can explore a range of schedule, scope, and staffing alternatives. Couple this with the ability to leverage project data - size, cost, schedule, and team performance - and you give your IT planning and decision-making processes a massive upgrade.

Join Laura Zuber for this PDU-approved webinar to learn how SLIM tools employ flexible project models and machine learning to provide information about projects that might not be obvious, enabling you to improve communication among stakeholders across the project lifecycle.

Watch the replay!

Whether you release on-demand or according to a regular schedule, being able to visualize how many sprints it will take provides instant feedback so you can explore a range of schedule, scope, and staffing alternatives. Couple this with the ability to leverage project data - size, cost, schedule, and team performance - and you give your IT planning and decision-making processes a massive upgrade.

Join Laura Zuber on Thursday, Sept. 12 at 1:00 PM EDT for this PDU-approved webinar to learn how SLIM tools employ flexible project models and machine learning to provide information about projects that might not be obvious, enabling you to improve communication among stakeholders across the project lifecycle.

Watch the replay!

We are pleased to announce the release of the QSM Software Almanac: 2019 Edition, an essential resource for anyone involved in the planning, management, or budgeting of software and systems projects and portfolios. This year's almanac focuses on agile development and the continued relevance and application of estimation and metrics.

The 2019 Almanac presents 18 articles from several perspectives, including both private and public. These articles show that there is indeed a compelling need to apply the basic principles of software estimation to projects, regardless of the methodology used, and that traditional metrics – even sizing metrics – can and should be applied to agile projects. Over the course of this book, the authors examine agile sizing approaches, effort and productivity, estimation best practices, as well as project and portfolio management best practices. All the articles offer research and insights into the foundational skills associated with parametric estimation and adapting those existing skills to account for changing conditions.    

Much of the content in the 2019 QSM Software Almanac is derived from the QSM Metrics Database, drawing data from over 13,000 completed software projects from North and South America, Australia, Europe, Africa, and Asia, representing over 1.2 billion lines of code, 600+ development languages, and 120 million person hours of effort.

We invite you to download the full, complimentary version of the 2019 QSM Almanac below.

Agile is all the rage today and companies are investing lots of capital to work within agile frameworks. Are these new methods the key to reducing project failure? When projects get behind schedule, a common reaction is still to add more people. Doug Putnam recently examined 390 contemporary applications of the same size, a significant portion of which used agile methods and tools, to see what matters more - staffing decisions or methodology. He discovered that while the additional staff reduced the schedule by approximately 30%, the project cost increased by 350%. The additional staff also created 500% more defects that had to be fixed during testing. Over the past 15 years, QSM has performed this same study in five-year increments and has found the same results -- staffing decisions have more of an impact on project success than any development methodology. In this article, Doug Putnam identifies a staffing "sweet spot" and outlines a step-by-step planning process  that uses predictive analysis and early estimation to more accurately account for staffing needs.

Read the article!

In many agile environments, the budget, team size, and schedule are fixed based on an organization’s predetermined targets for sprints or iterations. This leads many project managers to question if software estimation is even necessary. The problem is, without a reliable size estimate, the amount of functionality promised within the time and money constraints could be difficult to achieve and could cause the product delivery to be short on features, or late and over budget.

This is where scope-level estimation tools come into play. They can help evaluate whether targets are reasonable and, even if the schedule and budget are both set in stone, they can help figure out how much work can be delivered. This type of analysis helps set customer expectations and provides data driven leverage for negotiations.

The best estimation tools leverage empirically-based models, industry analytics, and historical data. They can even be used before iteration level planning takes place. They ensure that the overall goals are reasonable before detailed plans are developed. 

In the three views below, we see an estimate generated from a “Time Boxed” method. This is where the product manager was able to input the predetermined time, a productivity measure (PI), and a team size, to see how many story points could be completed within the set constraints. The analysis also includes a “sanity check” of the estimate, comparing it to an agile industry trend from the QSM Industry Database and their own agile historical data.

Scaled Agile (SAFe) is a methodology that applies Agile concepts to large complex environments.  QSM recently worked with an organization that had implemented SAFe to develop an estimation methodology specifically tailored to it.  This article discusses how it was implemented.

Software estimation typically addresses three concerns:  staffing, cost/effort, and schedule.  In the SAFe environment, however, development is done in program increments (PI) that in this case were three months in duration with two-week sprints throughout.  Staffing was set at a predetermined level and varied very little during the PI.  Thus, the three variable elements that are normally estimated (staff, cost/effort, and schedule) had already been determined in advance.  So, our job was done, right?  Wrong!  What remained to be determined was capacity:  the amount to be accomplished in a single PI.  And that was a very sore “pain point” for the organization.