Sizing

Sizing

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

Ask Carol: Sizing Alternatives When Cost Is an Issue

QSM hosts a free advice column for software professionals who seek help to solve project management, communication and general software project issues. Carol Dekkers is a QSM consultant and IT measurement and project management expert who speaks internationally on topics related to software development. Send your questions to Ask Carol!

Hi Carol:

Thanks for this excellent initiative. One of my key clients is planning to move away from FP counting as they think it’s expensive, takes time, does not measure non-functional work and also they do not want to invest in auditing the FP results. Instead, they are considering using LOC. We have tried explaining them all the shortcoming of LOC but no use. In fact we advised them to use SNAP along with FP but looks like they are just focusing on cost!

In your article on 'Size Matters', I noticed you had mentioned few other techniques to measure size like RICE Objects and Implementation Units. Would like to learn more about these and would like to understand if these are industry standards. Can you please share some insights?

– Sizing Enthusiast

Dear Sizing:

Because you are someone who knows the value of functional sizing (aka function points,) it is frustrating when management focuses on the cost of measurement rather than the value delivered.  I’m wondering whether there is a disconnect between the perceived value and the cost of FP counting. There are a couple of potential issues here that I’d like you to consider before we get into the sizing alternatives

Blog Post Categories 
Sizing Ask Carol

Ask Carol: No Matter What, in Project Management, Size Matters

QSM will be hosting a new free advice column for software professionals who seek help to solve project management, communication and general software project issues. The first few scenarios are based on questions we receive all the time. Carol Dekkers is a QSM consultant and IT measurement and project management expert who speaks internationally on topics related to software development. Send your questions to Ask Carol!

Dear Carol: 

I’m a systems analyst working for a telecom company and I have several projects on the go at the same time.  Our PMO (Project Management Office) told us that now we have to start tracking the size of our projects both at the beginning and at the end.  I can’t believe this – it’s just more metrics and (redundant) data.  I already track project size because I do time reporting (by project) and all they need to do is add up my hours at the end and voila, you’ve got the project size: the more hours it took - the bigger the project.  They don’t seem to get it and I’ve asked for an exemption from this overhead task. Their response was to enroll me in a two day sizing course!  What can I do to prove to them that they already have the size because I keep track of my hours? 

- Frustrated in Seattle

Dear Frustrated:

Blog Post Categories 
Sizing Ask Carol

Velocity: What Is It?

It’s easy to get confused or overly concerned about measuring velocity. Actually, the concept is almost embarrassingly simple. Velocity in Agile is simply the number of units of work completed in a certain interval. Like in many fields, Agile proponents appropriated existing terminology.

Here is one typical definition, from agilesoftwaredevelopment.com:

In Scrum, Velocity is how much product backlog effort a team can handle in one Sprint. Velocity is usually measured in story points or ideal days per Sprint… This way, if the team delivered software for 30 story points in the last Sprint their Velocity is 30.

Velocity as a capacity planning tool used in Agile software development is calculated from the results of several completed sprints. This velocity is then used in planning future sprints.

The concept of velocity comes from physics. In physics, velocity is speed and direction, in other words, the rate of change of position of an object. Speed can be measured in many different ways.

In software, speed is frequently measured as size per unit of time (sometimes this has been called delivery rate). The measure of size could be any of the common size measures: lines of code, function points, requirements, changes, use cases, story points. The measure of time could be calendar time (month, week, day) or it could be specific to a project (sprint, release). As to direction, in software hopefully the direction is positive, but sometimes projects go backwards (for example, backing functionality out of a system).

Blog Post Categories 
Sizing Agile