In the interest of supporting the software development industry, the following resources are available free of charge.
This is the fifth article in the QSM Agile Round Table series. The QSM Agile Round Table was formed to discuss the role of estimation in agile environments. QSM customers shared their questions, challenges, and experiences on the relevance and benefits of scope-based estimation in an agile environment. This article continues the focus from the previous article on determining size in a consistent enough manner across multiple products, projects, and agile teams so that you have good historical data on which to base an estimate. QSM's Andy Berner looks at other sizing units besides story points, in particular function points and source lines of code.Read the article
This is the fourth article in the QSM Agile Round Table series. The QSM Agile Round Table was formed to discuss the role of estimation in agile environments. QSM customers shared their questions, challenges, and experiences on the relevance and benefits of scope-based estimation in an agile environment. The previous article in this series, “Big Rock Estimation” written by Aaron Jeutter from Rockwell Automation, addressed the question of how to determine the size of a release absent of a “big upfront requirements phase”, and thus when the requirements are only known at a very high level and subject to refinement and change. The next three articles will focus on determining size in a consistent enough manner across multiple products, projects, and agile teams so that you have good historical data on which to base an estimate. They will also show how to apply these techniques with the SLIM Suite of products.Read the article
For a number of years, the federal government has been on a mission to reduce waste and enhance efficiencies across departments, including IT. But according to the CIO Council’s 2017 State of Federal Information Technology report, 43% of the federal government’s $80 billion in IT projects cataloged in September 2016 were listed as over budget or behind schedule. In this article for GCN, Doug Putnam takes a look at some of the common pitfalls that lead to project cost and schedule overruns and how parametric estimation can help government CIOs and their teams avoid these traps.Read the article
Developing software within the DoD presents a unique set of challenges, including but not limited to budget cuts, Congressionally mandated changes, changing software requirements, and so on. It should come as no surprise, therefore, that cost estimators have faced significant challenges when estimating systems in the Defense arena. A recent initiative put forth by the DoD was to improve its estimation process by leveraging historical data collected from forensic analyses of recently completed software development efforts. This article by Taylor Putnam-Majarian and John Staiger, discusses (1) some of the challenges faced throughout this initiative, (2) the data collection process, and (3) how one can leverage data to improve cost estimates. This article was originally published in Crosstalk Magazine.Read the article
As we embark on 2017, which is also the 30th anniversary of IFPUG Bylaws, there are reports that the software development industry is making progress. The 2015 Standish Group CHAOS report cited that agile projects are, on average, three times more likely to be successful than waterfall projects (based on their survey of over 10,000 projects.) The not-so-good news, however, is that the percent of successful projects (defined as on-time, on-budget, and with a satisfactory result) hasn’t changed much since the first CHAOS report in 1996, and hovers around 40%. The top three success factors in the 2015 report were not technical: 1. Executive Support, 2. Emotional Maturity and 3. User Involvement (agile processes ranked #7.) The need for software sizing measures to support project estimating remains just as critical as it was 30 years ago, yet IFPUG function points are not used as extensively as they could be to support software sizing. Rather than “throwing the baby out with the bathwater,” so to speak, or creating new metrics to solve old problems, Carol Dekkers and Joe Madden suggest a new way to repurpose function points to achieve estimating successes today. This article was originally published in IFPUG's Metric Views.Read the article
No one got into software development to budget. Developers love to code and create. If they wanted to create budgets, they’d have become accountants. Still, creating a development plan for 2017 is essential and will inevitably require budgeting and estimating, a process that should be done in partnership with business teams. This will ensure the creation of software that cost-effectively meets their needs. In this article originally published on SD Times, Doug Putnam identifies three strategies for better budgeting and planning in the new year.Read the article
The most effective project portfolio planning brings IT managers and business leaders together to prioritize, scope and staff initiatives as a single team with common goals. In doing so, the process fosters better working relationships — and provides a roadmap for delivering value to the organization. In this article for Projects at Work, Larry Putnam, Jr. outlines best practices on how to determine the maximum capabilities that can be delivered within the confines of budgets, resources, and time.Read the article
Big Rock Estimation: Using Agile Techniques to Provide a Rough Software Schedule / Resource EstimateBy Aaron Jeutter ( February 2017 )
This is the third article in the QSM Agile Round Table series. The QSM Agile Round Table was formed to discuss the role of estimation in agile environments. QSM customers shared their questions, challenges, and experiences on the relevance and benefits of scope-based estimation in an agile environment. The Round Table spent several meetings on the key topic of sizing an agile release. The discussion centered around two main questions:
- How can you determine the size of a release early in absence of a “big upfront requirements phase,” and thus when the requirements are only known at a very high level and subject to refinement and change?
- How can you determine size in a consistent way across multiple products, projects, and agile teams so that you have good historical data on which to base an estimate?
This and the next article in the QSM Agile Round Table series are based on those discussions. Aaron Jeutter, a participant in the Round Table from Rockwell Automation, presented 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.Read the article
The time has come to begin the annual ritual: IT budgeting. Not only is this task difficult, it is made worse by the fact that most organizations do it in an overly simplistic way. This often results in up to 40% of the projects grossly missing the mark, which wreaks havoc on the enterprise resource plans and results in disappointed business stakeholders. What is if it didn't have to be this way? In this whitepaper, Doug Putnam outlines QSM's five step budgeting process: data collection, feasibility assessment, building the actual budget, adjusting "at risk" and overly conservative projects, and finally, identifying alternatives to add value to the business or to fit organizational budget constraints. This budget planning data can be fed into a Project Portfolio Management (PPM) system to facilitate specific resource allocations and portfolio management.Read the article
Instead of debating #YesEstimate vs. #NoEstimates, we can ask a more useful question: “what should we estimate and why?” To answer this, we need to distinguish between consumable value and potentially deliverable software. Both are useful concepts but for different purposes. By choosing small enough developer-sized bites, we can time-box potentially deliverable software to get frequent feedback and review. But a meal that provides consumable value that satisfies our users and customers must consider the tradeoff of benefits to both the business and the consumer. In the second article of QSM's Agile Round Table series, Andy Berner explains why setting goals for consumable value and estimating what it takes to reach those goals are both needed to guide the choices every organization needs to make about what to develop and how to allocate resources. A version of this article was originally published on AgileConnection.Read the article