Backlog Sizing Essentials
Examine each User Story AND the set
ScopeMaster automatically provides a size estimate based on the text of the user story.
Why Automated Sizing with ScopeMaster is better than Team Sizing
Not only does ScopeMaster provide a reasonable size estimate for the backlog but it can do so effortlessly, instantly and can size backlog items that are missing!
Software Backlog Sizing Automated by ScopeMaster®
Software backlog sizing and estimation are normally wasteful time-consuming and gamed. Yet reliable estimates is essential for sound investment decisions and effective planning.
Estimating software backlog size (and subsequently cost and schedule) is important to give managers an understanding of how much it will cost and how long it will take. Managers and executives are constantly faced with difficult decisions about software work. On larger projects, budgets and schedules are frequently exceeded, both of which lead to considerable waste and inefficiencies. Managers need to know the likely cost and duration to develop software so that they can plan accordingly. They are expected to make dependable decisions about priority and staff allocation and yet often do so without reliable software estimation of the time and effort needed.
Most software professionals believe that it is impossible to estimate software development work, or that it is very time consuming. This is not so.
Why are developer estimates unreliable?
Developers often struggle with estimation. Estimation using techniques such story points or t-shirt sizing, is really just a proxy for guessing hours or days of work. The teams will argue otherwise but that is mostly obfuscation to promote. When developers provide estimates for a piece of a work, they may deliberately understate the work perhaps to “win” the work and protect their work. They may also overestimate to avoid having to do some work that they don’t want to do.
Misuse of Developer Estimates is Prevalent
Once developers have provided a manager with an estimate of a user story, a sprintful of work or even an entire backlog, the manager might then go on to use that estimate as a target, a measure of control or even a commitment, all of which are unsuitable uses of basic effort estimate.
Under-estimating is Human Nature
Developers almost always underestimate the time and effort actually required to get software delivered. It is human nature to do so. They only consider the factors that they know about, and yet with software, there are often unknowns that cause delay, theses are rarely allowed for in technical estimation. Moreover developers’ initial proposals are usually low in order to “win the work”.
How to Estimate Software Product Backlog, Reliably?
Tens of factors can affect the time and effort to develop software (such as complexity, work environment, executive support, technical experience, requirements volatility). The single most significant factor in determining effort or cost, is size, specifically functional size.
Software Functional Size is the bedrock of Backlog Estimation
Once you know the functional size, you can quickly derive valid estimates for other dimensions, such as:
- staffing
- time to develop
- costs
- tests needed to achieve suitable quality
- and much more
What is Functional Size?
Functional size arises from Functional Size Measurement (FSM). It is a mature and proven standardised technique for software sizing. It is a formal engineering practice approved by the ISO standards groups. It is agnostic of the technology and development methodology. Functional size is a universal measure that applies to all types of software. It is considered from the users perspective. It is objective and valid, and consistent. Two people measuring the functional size should come up with the same number each time. The unit of measure is the function point, specifically the COSMIC function point or CFP. The CFP can be estimated or counted (exactly) just from requirements and specifications. The functional size is independent of the coding language used to develop it. FSM has been around for many years and has proven to be the most reliable measure of software size. FSM allows you to estimate or measure size before, during and after the code has been written.
Ground breaking Product Backlog Estimation
ScopeMaster is the first and only tool to reliably estimate functional size directly and automatically from a backlog of written requirements. Don’t just take our word for it though. Experts and academics around the world agree that ScopeMaster® is a breakthrough automated sizing tool: Academic validation of ScopeMaster as an automated sizing tool.
Bring certainty to your software work with automated functional size measurement.
For more on COSMIC functional size measurement, visit https://www.cosmic-sizing.org
The great thing about knowing the size before coding, is that you can allocate the correct amount of time and funds to get the job done. Just by knowing the size, you can usually save 10% or more on a larger software project, sometimes even more.
Automated Software Estimation with ScopeMaster
Three leading standards automated:
ScopeMaster was conceived as a tool to automate the clerical work of measuring the functional size of software from requirements. “The reason I set out to write a tool to do this is because, as a software project manager, I found that functional size is the single most significant factor that I need in order to manage a project successfully.” Colin Hammond, Founder.
ScopeMaster interprets the functional intent of the user story or software requirement, and so is able to automate functional sizing, which can then be used for further estimation of software development.
Not only is ScopeMaster much faster than measuring manually (at least 4 times faster), it costs substantially less than manual sizing, certified counters are scarce and ScopeMaster takes much of the drudgery out of doing the job. ScopeMaster “reads” the requirements, interprets the functional intent and then sizes them accordingly. It can estimate size at about 3 CFP per second. You could size a 1,000 CFP set of requirements (about $1m of outsourced software) in about 2 or 3 minutes. You might then review the results to a) correct any requirements mistakes and b) verify the functional size of each requirement. Once verified by the analyst, the estimate becomes an exact count/measurement, which can even be used for fixed price outsourcing of software development work.
COSMIC Functional Sizing
Over the years, several variations of functional size metric have been created. Only five have achieved ISO recognition (COSMIC, IFPUG, Mark II, NESMA and FiSMA). IFPUG, Mark II, NESMA and FiSMA are all similar in that they are derived from the original ruleset created by Allan Albrecht at IBM back in the 1980’s. The COSMIC functional size methodology evolved from earlier methodologies, specifically designed to address the shortcomings of them. The key advantages that make COSMIC Sizing methodology more relevant to modern software are:
- It is based on software principles, dealing elegantly with interconnected software layers and software architectures.
- Estimates and measurements can be made before all requirements are known – highly suited to Agile development.
- It has been automated and so takes negligible learning.
Story points are prevalent across all Agile projects, they are a team-specific proxy measure for effort. Each team has a common understanding of the magnitude of a story point, it is typically in the order of a few hours of effort, but there are no strict rules. Story points are not a universal currency. They are not a standard and they cannot reliably be used to compare teams or projects. Story points are a useful internal indicator of anticipated effort, if no other means of estimation is available. Function points however are universal, standard and highly applicable to Agile development as much as any other development methodology. Click here to read more on the merits of CFP vs Story Points
Size is the Cornerstone of Software Estimation
Once you know the functional size in COSMIC function points (CFP), you can quickly establish other metrics that are directly related to size, such as cost, effort and schedule. Once the size in CFP is established you can then use industry conversion values that map function points to effort, cost and schedule. Rather than use industry conversions, you can use your own historical project data to establish your own velocity benchmarks.
Agile Estimation
Rather than burn time discussing story points or playing with Fibonacci cards. Agile estimation, in our experience is best achieved via functional sizing with COSMIC FP.
What can you estimates based on size?
- Velocity (average CFPs delivered per week)
- Schedule (number of weeks needed to deliver)
- Cost (total cost to design, develop, test and deliver)
- Effort (effort needed to design, develop, test and deliver)
- Quality (defect potentials for each constituent of the delivery)
How fast can you derive estimates?
Manually, a competent analyst can count (measure) function points at a rate of about 100-500 FP per day (approx $100k – $500k of software). This depends on the quality and clarity of the requirements and specifications. The speed also depend on the experience and ability of the analyst. With ScopeMaster you can expect to achieve these rules about 4 times faster.
Estimating As you Write User Stories
Using the ScopeMaster Story Analyser for Jira, you can estimate your stories’ functional size without even leaving Jira. The text of your user story is analysed by ScopeMaster’s powerful language engine to detect the functional intent and functional size.
Size is not the only factor that determines software costs and schedule, but it is the most significant one.
Problems with story points and T-shirts
- Inconsistent
- Game-able
- Non-linear
Story points are a team based opinion about the amount of effort it might take to build some software from a developer’s perspective. Story points are essentially a proxy for effort estimates, e.g. one story point might be the equivalent of 1 ideal person day. They are highly subjective and dependent on the opinions of the team. They vary from team to team and even over time within the same team. Their inconsistency and game-ability renders them impractical as a reliable engineering metric.
For those who consider estimation to be harmful, unimportant or just too difficult, check out Steve Mconnell’s excellent article on why estimation is an important and valuable skill that project managers need.
