Sizing

Sizing

New Article: Determining a Gearing Factor for Story Points

Agile Stories Gearing Factor

QSM recently published the sixth 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 two articles focused on determining size in a consistent enough manner across multiple products, projects, and agile teams in order to have good historical data on which to base an estimate. They looked at several possible units of measure for software size, including story points, function points, and source lines of code (SLOC). SLIM-Estimate and SLIM-Collaborate permit any of those units, as well as others, to be used for software sizing. In order to use a sizing unit other than SLOC in the SLIM tools, you must assign a gearing factor.  For function points, gearing factors are discussed here. In this article, QSM's Andy Berner addresses ways of choosing a gearing factor for story points.

Read the article!

Blog Post Categories 
Articles Agile Sizing

New Article: Sizing Agile Projects Consistently

Agile Sizing

QSM is pleased to share 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 written by Andy Berner 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 full article!

Blog Post Categories 
Articles Agile Sizing

Not Just for Software: How Estimation and Sizing Can Help You Plan a Successful IT Infrastructure Project

Estimation and Sizing for Infrastructure

This post was originally published on Linkedin. Join the QSM Linkedin Group and Company Page to stay up-to-date with more content like this.

While creating technology is about solving everyday problems, the act of creating technology is about solving design problems. This applies to any type of technology project, regardless of its purpose or size. Organizations must put as much thought and consideration into the design of their underlying IT infrastructures as they do in the design of their software projects. Both require careful sizing, estimation and planning.

Of course, installing, configuring and testing IT infrastructure is different than developing a piece of software. A typical IT infrastructure project could include:

  • Server room buildout (clean power, fire prevention, disaster recovery, cabling, etc.)
  • Network connectivity (local and wide area network)
  • Installation of computer server hardware (can be physical or virtual)
  • Configuration of system software on the servers (operating system, database, email server, web server, security template, etc.)
  • Configuration of computer desktops, laptops, smart phones. peripherals and other Internet of Things (IoT) devices 

Together, the hardware and software formulate a truly complex system where all of the parts are interconnected.

Blog Post Categories 
Estimation Sizing Infrastructure

Three Strategies for Successful 2017 Project Portfolio Planning

This post was originally published on Linkedin. Join the QSM Linkedin Group and Company Page to stay up-to-date with more content like this.

As we move closer to the end of the year, many of us are in planning mode. We’re working hard to determine which development projects are going to get done next year, and which ones may have to wait their turn until 2018.

No one should go it alone, though. Business executives need input from IT managers to truly gauge the feasibility of developing the projects that are on their list. Likewise, IT managers need insight into the expectations of business executives so they can produce the products they need.

That’s what makes project portfolio planning so essential. It brings business stakeholders and IT managers together by allowing them to communicate with each other about needs and expectations, and to find common ground that leads to realistic project estimates that help shape the course of successful development for the next 12 months.

It also helps establish a clear product roadmap. It’s not uncommon for organizations to start out with a long list of “to-do’s” every year, but doing everything is simply unrealistic. Therefore, it’s important to identify and prioritize projects that will bring your company the best ROI and help it meet overall strategic goals over the course of the next year.

New Agile Article: Sizing Matters

Cone of Uncertainty

Agile is about adapting to change, not completely abandoning documentation or dismissing helpful planning and estimating inputs. In this article for Projects at Work, QSM's Jay Daniel explains how the benefits of an agile approach can shine brighter when used in conjunction with a fundamental development practice such as sizing.

Jay Daniel is a Professional Services Manager with QSM's Consulting Services team. He is an IT professional that has served in a variety of consulting roles, ranging from Program and Project Management to providing Independent Verification & Validation (IV&V) support to clients. For the past five years, Jay has focused his attention on agile methodologies in the implementation of software development efforts. He is a certified project manager (PMP), scrum master (CSM), and product owner (CSPO).

Read the full article!

Blog Post Categories 
Agile Articles Sizing

The Lowly Line of Code (Part One)

“I'm sorry, Dave. I'm afraid I can't do that” – HAL 9000[1]

Source lines of code (SLOC) is a measure of software size, in use since the 1960s. This blog post describes various uses of SLOC from the perspective of software measurement.

There seems to be a love/hate relationship with the line of code measure. Despite its broad and continuous use (or perhaps because of it) SLOC seems to get the blame for many a failed software project, process improvement or software metrics initiative. There are even those who claim that “…in many situations usage of LOC metrics can be viewed as professional malpractice…”[2] But, as you will see, SLOC has many benefits, when used intelligently.

Blog Post Categories 
Metrics Sizing Software Sizing

Should Task Planning Occur Before Software Estimation?

I work for QSM, a leading software project estimation and demand management company. We focus on top-down estimation, meaning we figure out the total project duration and effort before any detailed planning occurs. We use SLIM-Estimate also known as the Putnam Model. Larry Putnam Sr. introduced SLIM in 1978. It is one of the leading software estimation tools in the world, validated with over 35 years of industry leading research and updated regularly with the latest technologies. 

Many people call us for help with team size software project estimation, they want to see how many people it’s going to take to deliver a specified amount of functionality within a certain duration and budget. At the time they call us they are often using task level planning tools to try to figure this out. 

The problem is that it’s tough to allocate people and the number of hours they will work when they haven’t figured out the specific requirements of each task and when they haven’t estimated the total duration and effort for the overall system. A manager could spend days creating a task level plan that doesn’t add up to the overall project duration and budget that is needed to deliver the functional requirements. When it doesn’t add up then re-planning has to take place costing more time and money. This is why QSM recommends estimating the big picture first, the scope level. 

Blog Post Categories 
Estimation Process Improvement Sizing

Webinar Replay - QSM's Software Sizing Infographic: A Visual Aid for Understanding Software Size

Software Sizing Infographic Webinar

If you were unable to attend our recent webinar, QSM's Software Sizing Infographic: A Visual Aid for Understanding Software Size, a replay is now available.

Software size, the amount of functionality in a given software release, is arguably the most critical of the five core metrics of software estimation. There is little point in tracking effort, duration, productivity and quality if you are unable to quantify what you are building. Yet, despite its critical importance, software sizing is often a difficult concept for many to understand and use properly in the estimation process. In this webinar, Joe Madden gives an overview of QSM's Software Size Matters Infographic, which addresses the challenges of measuring software size and identifies the most popular sizing methods and when to use them. With over 17 years of software sizing experience, Joe provides case studies and best practices for real world application.

Watch the replay!

Blog Post Categories 
Sizing Webinars

Introducing QSM's Software Sizing Infographic

QSM Software Sizing Infographic Software size, the amount of functionality in a given software release, is arguably the most important of the five core metrics of software estimation.  There is little point in tracking effort, duration, productivity and quality if you are unable to quantify what you are building.

Yet, despite its critical importance, software sizing is often a difficult concept for many to understand and use properly in the estimation process.  Sometimes a picture is better than 1,000 words.  With that ideal of visual simplicity in mind, we developed a software sizing infographic that helps explain:

  • Why we care about size
  • Challenges in sizing
  • When size should be measured during the software development life cycle (SDLC) to narrow the cone of uncertainty
  • The difference between functional and technical size 
  • The most popular sizing methods and when to use them

The infographic begins by introducing the five core metrics of software estimation (size (scope), schedule (duration), effort (cost), quality (defects) and productivity) and the nonlinear relationship between them.

Blog Post Categories 
Sizing Software Sizing Estimation

Ask Carol: T-Shirt Sizing for Early Estimates?

Dear Carol: 

I work in IT and we do a lot of our software development projects based on pre-defined delivery dates (no one really knows where they come from).  Sometimes this works out, but usually we end up delivering the project months late because we had no idea the project was as big or as complex as anyone had originally thought. A friend says his company uses “t-shirt sizing” for project estimates and I’ve never heard of it. What can you tell me about this new approach?

- I’m willing to learn from the fashion industry 

Dear I’m willing:

T-shirt sizing has been around in one form or another for a few years but it is not a widespread mainstream estimating method.  It is a quick and dirty way to estimate software size using ranges of size.  Once you have the relative size (e.g., XS, Small, Medium, Large, XL, XXL, or larger), you can enter it into several different estimating tools as the size on which to base the estimate. While this doesn’t give you a guaranteed size for the software to be delivered, it is better than not having any idea of the size.  Size (scope) is one of the three main tenets of the triple constraints (scope, budget and schedule) for project management.  Given one, you can estimate the other two.

Blog Post Categories 
Sizing Estimation Ask Carol