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.
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:
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!
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!
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!
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.
Scope creep is a frequent topic of discussion among project management professionals. A recent Project Management Institute (PMI)® i Community Post, Fighting the Dreaded Scope Creep, reported some responses PMI members offered as their weapon of choice. The various suggestions can be summarized by two general practices:
Sizing is arguably the most challenging part of any software estimate. Without a notion of functional size, managers may find it difficult to negotiate realistic schedules based on their demonstrated ability to deliver software. They are unable to show empirically why the twelve person team that worked so well on a 150,000 ESLOC project over six months not only fails to deliver a 75,000 ESLOC project in half the time, but produces an error-ridden product that infuriates the customer. Unlike manufacturing shoes, software development is full of non-linear relationships between size, time, effort, and defects. What data driven estimation does successfully is arm managers with the ability to sanity check their current plans against past performance and negotiate achievable outcomes based on a realistic assessment of how much functionality can be built with a set time frame and resource profile.