Monthly Archives: February 2007

Agile Development and Software Maintenance Costs

February 28, 2007Agile, Product Management, ROI, Software developmentScott Sehlhorst

broken window

Over 90% of the cost of software development is software maintenance (cite). This alarming trend was predicted as early as 1972. McKinsey suggests that CIOs should spend no more than 40-60% on maintenance. Gartner’s IT Spending and Demand Survey (2002) reports that CIOs are spending 80% of their budgets on maintenance (p12 of presentation). Agile development can help reverse this trend.

The Cost Trends of Software Maintenance

Jacoozi published an analysis of the impact of continuous refactoring on software maintenance costs. Continuous refactoring is an element of agile software development, where the developers continuously make minor improvements to the architecture and design as they maintain the code.

(larger image)

Thanks to Levent Gurses for providing this modified version of the chart from his article, Continuous Refactoring and ROI. In his article, he discusses both recurring “big bang” refactoring (the pink curve) and continuous refactoring (the green curve).

What Levent’s chart shows with the black line is that the cost of maintenance grows at a significant rate over time when you don’t refactor the code.

We can re-use the diagram from our earlier analysis of agile development and ROI, and overlay this cost structure. The green curve represents sales volume, contrasted with the shaded curve representing development costs.

cost of waterfall

In the product lifecycle diagram above, there is an initial “hump” of development cost. Note that when you are using incremental development, the hump extends past the end of the development stage of the product life cycle.

The largest part of the shaded area represents the ongoing costs – 90% of which are maintenance costs. Note – we are assuming that companies use a rational investment strategy – they continue to maintain the software until the costs equal or exceed the revenue. The investment should stop when the opportunity cost of continued investment exceeds the benefits of continued investment.

Broken Windows

Continuous refactoring is making small investments in improving the code over time. The absence of those investments allows the code to grow more expensive to maintain over time. Gartner estimated that 50% of the cost of ongoing maintenance labor is spent trying to understand the existing code base. This is very inefficient.
In The Tipping Point, Malcolm Gladwell described this phenomenon by analogy to the broken windows in East New York City. This is just one gripping example from his book of the same title.

As the code gets more convoluted over time, these two factors serve to increase costs dramatically – the increased difficulty of doing the job, combined with increased apathy about doing it right. Costs would go up simply because the code gets larger (as the software is expected to do more and more). These factors accelerate the rate at which the phenomenon occurs – consistent with Levent’s faster than linear cost growth function.

Fixing The Windows

When faced with the challenge of reducing the ongoing maintenance costs, you have a few choices:

Eliminate Ongoing Maintenance and Development. This was the Autodesk strategy (fire the engineers, milk the product for revenue). It worked great for a very short time. Profit growth was tremendous. This of course accelerated the decline in sales, eliminating revenue (and therefore profit).
Reduce Spending On Maintenance and Development. Simply reducing the budget has all of the negative impact of cutting the budget, but with fewer gains. A reduced budget (with no other changes) increases the frustration both of unstatisfied customers and of overwhelmed developers. This is a bad idea.
Refactor The Code To Improve Efficiency. You can make ongoing maintenance more efficient by making the code easier to understand and modify. This generates cost savings – the “big money” in ROI calculations.

Improving efficiency reduces the costs of ongoing development, as the following diagram shows:

savings from continuous refactoring

Other Benefits

By reducing the cost of ongoing maintenance, you can improve the profitability of the product. You also free up resources for investment in new product development. This helps move your organization to McKinsey’s recommended 40% to 60% maintenance budget.

You will also get intangible benefits and improved efficiency by reducing the number of broken windows in the product’s code base. This results in increased motivation of the team members and greater job satisfaction. The increase in motivation will decrease the cost of development of other functionality.

You may also extend the useful life of the product – by extending the amount of time when ongoing maintenance is still profitable. This additional development work could result in increased sales – extending the product life cycle.

Product Life Cycle and the ROI of Agile Development

February 27, 2007Agile, Product Management, ROI, Software developmentScott Sehlhorst

agile skateboarder
The product life cycle is a description of the presence or behavior of a product in the marketplace over time. The framework for description is a function of the sales volume of the product versus time. Over time, products are created and introduced, and sales grow, peak and decline. The product life cycle uses phases to describe these different periods in the life of a product. Understanding the product life cycle is also key to calculating the ROI of agile development.

The Five Stages of A Product Life Cycle

There are five product life cycle stages. The stages are defined as having different sales-growth characteristics

Development Stage. In the development stage, there are no sales – the product is being created and is not available.
Introduction Stage. The introduction stage starts with the first sale and then sales begin to grow. Sales growth is slow at first but accelerating.
Growth Stage. This is the period of rapid growth in sales for the product.
Maturity Stage. This phase is characterized by growth as well, but the sales growth is decelerating. Sales volume reaches its maximum at the end of the maturity stage.
Decline Stage. This phase represents the period of declining sales – they may still be very high, but they are declining.

Here is the product life cycle diagram [credit to wikipedia and NetMBA for both using this approach to drawing the graph]:

product life cycle sales volume graph

The area under the curve is total sales. This model was developed with traditional product development in mind.

What About Agile Development?

Agile development uses an approach of incremental delivery to deliver a partially-completed product to market earlier. As long as the product is “complete enough”, it will shift the curve to the left. By shortening the period of time with no product revenue (aka Development), we spend more of our time in the last four stages of the product life cycle.

Think of beta releases of software. GMail, for example, was released as a beta a few years ago. The product was just finally released to the general public in the last month. Think of all the advertising revenue that Google earned during the beta period – while GMail was being completed. If they had waited until the product (and infrastructure) were complete, and not released GMail until last month, Google would have lost all that revenue.

If we take the most conservative approach to modeling sales with an agile process, the graph would look like the following:

agile product life cycle

The sales volume curve is shifted to the left without changing its shape. The exact same growth curve applies to the product (this is the conservative assumption). The decline in sales continues to decline. The difference is that our previous time horizon (which remains fixed) now includes additional sales.

The time horizon stays fixed because releasing the software earlier neither reduces or increases our ability to predict the future. Our net present value calculations will be based on time, not “time with a product in the market.” In a concrete example: Assume we are willing to base our financial decisions on a five year forecast. Having an incremental release six months before the product is complete does not have any effect on our decision to look out five years.

It may be that sales are increased by getting to market earlier, but that is a less-conservative assumption. By getting to market earlier, when we are in a race to capture market share, we may ultimately capture more of the market. An example might be Intel’s recent multi-core processor launch. By getting to market faster than AMD (with a comparable product), Intel will probably sell more CPUs than they would had their launch been delayed until AMD was ready with a competitive product.

It may also be reasonable to assume that sales will peak at the same (fixed) point in time in the future. This would further increase the benefits of incremental delivery. One way this might make sense is if our product is filling a temporary hole in the market, and we know that the hole is going to be filled on a given date. An example might be an emulator that allows people to run Windows Vista programs on Windows XP. The time-table for transitioning to Vista is unchanged by our release schedule, and is the dominant factor in our sales forecast. Therefore our forecasted peak would be unchanged.

Conclusion

This is a handy visualization for the conservative calculation of ROI of agile development. Note that this only shows sales, it does not show costs. The costs of agile (versus non-agile) development will be the topic of another article. This is only half of the picture.

8 Stages of Corporate Usability Awareness

February 26, 2007Software development, Usability, UXScott Sehlhorst

eight
Jakob Nielsen identifies 8 levels of adoption of usability by corporations. He calls them the stages of corporate usability maturity. There is definitely a continuum of adoption and appreciation for usability in companies today. By understanding the eight levels we can determine how best to increase the commitment to usability on our projects.

Reference

Nielsen describes maturity stages 1-4 and 5-8 in separate articles, found via his blog.

Stage 1: Hostility Towards Usability

The system determines how people will use it. Developers are not interested in focusing on how people will want to use the software. At most, developers can be convinced to help write the doc. The focus is on teaching users how the software works, not writing the software to work like the users.

stage 2 Stage 2: Developer Centered Usability

Members of the development team develop an awareness of usability, conceptually. Unfortunately, developers approach software very differently. Cooper calls programmers homo-logicus, to distinguish them from actual human users. Because programmers understand how computers work, they have very different expectations than everyone else.

Stage 2 may be effective if you’re writing software for other developers. The designers working on eclipse and subversion don’t need to design it “for your mom.” So when they incorporate usability from their own perspective, it will at least have a lot of overlap with the perspective of the target users.

Developers want to achieve software product success. Your team just needs to be asked to think about how they would use the software. One strategy that may work is to present two perspectives: inside-out and outside-in.

Inside-Out Design

Think of the earliest automobiles. The driver had to get in front of the car and crank start it – because that’s where the drive shaft was. They had to pull on a hand brake to stop the car because that’s how the brakes worked. Neither was a particularly usable design. The “under the hood” engineers built it so it would work, and then “interface guys” connected an interface to the inner workings.

Outside-In Design

Now think about the Dick Tracy wrist-communicator. An artist designed what it would do, how big it was, and how to use it. Then engineers spent the next few decades figuring out how to squeeze radio-transmitted video signal hardware (and a camera) inside the form factor. This is outside-in design.

stage 3 Stage 3: Skunkworks Usability

The outside-in concept begins to take root “under the radar” on projects within your company. Some representative users are brought in to provide feedback on designs. Usability testing has an impact on some projects.

Nielsen points out the distinction between this level and higher levels – funding and recognition. At this point, it is starting to happen naturally, but it is neither funded nor actively promoted.

To get from stage 2 to stage 3, find some receptive team members, and buy them a book or two on usability or interaction design. Send them to Neilsen’s website, or Kathy Sierra’s or even our usability articles archive which links to those sites and others.

stage 4 Stage 4: Dedicated Usability Budget

Usability becomes intentional and systemic. Your company has usability funding for its projects and usability testing becomes widespread. Nielsen describes the attitude succinctly:

At this stage, the company mainly views usability as a magic potion that’s sprinkled sparsely over a user interface to shine it up.

You might reach stage 4 because an exec makes a connection between the magic potion and the success of a stage-3 project that applied usability. Instead of hoping that will happen, convince your managers of the importance of funding – get a stage-3 project, demonstrate the benefits, and then expand.

Neilsen also adds:

you can’t help but make dramatic improvements the first time you do a bit of usability on a project

This should be an easy sell.

stae 5 Stage 5: Managed Usability

Your company now has a usability group with a charter. The usability team, while still focused primarily on user-testing, is beginning to approach projects more consistently. They keep records of results, learn from each other, and begin introspectively improving.

Nielsen also makes the distinction that at stage 5 there is a person responsible for usability thought-leadership across the company.

If anyone has successfully helped their company move from stage 4 to stage 5, please share how you did it in the comments. We haven’t been involved in this transition before, and would be inclined to use the same methods we use to reach stage 4 – only more so. There are surely better ideas (or failed ideas) out there that everyone can learn from. Tell us all in the comments on this article.

stage 6 Stage 6: Systematic Usability Process

A formal user-centric design process is in place. Your company is tracking the quality of usability across projects and identifying trends. The usability budget is big enough that key projects get the needed funding.
stage 7 Stage 7: Integrated User-Centered Design

Your company is now doing pre-emptive field studies or working with companies like Expero, Inc. to help them. [Disclosure: I’ve worked with Dr. Morkes, one of the founders, in the past, and he’s awesome.] Nielsen also suggests that tracking of usability results is becoming quantitative instead of qualitative.

We think the notion of improving user-understanding before projects start is the key distinction.

stage 8 Stage 8: User Driven Corporation

The company evolves into one where attention to the user-experience affects not only all projects, but corporate strategy. Perhaps your company looks for opportunities based on usability issues with current solution approaches. Usability extends beyond product development decisions and into other areas of the company – anything customer facing, for example.

Conclusion

This is a long and valuable path. Nielsen concludes that it can take a company 20 years to move from stage 2 to stage 7, and perhaps another 20 to reach stage 8. Some companies, like 37signals seem to buck the trend by starting out with a high level of user focus. Perhaps the founders get credit for previous experiences at other companies?

Wherever you are, the next stage is clearly better. Focus on that. And come back here to reread the list every few years :).

Flashback: A Year Ago This Week on Tyner Blain [2006-02-24]

February 24, 2007FlashbackScott Sehlhorst

car mirror

Software Requirements Specification Iteration and Prototyping

giant gearbox

Developing great software requirements demands iterationIn our previous post of an example of the software development process, we showed a linear flow through the process, as depicted in several posts over a couple weeks. What we failed to show was any of the iteration cycles, as Deepak points out by asking a great question in the comments on that post. In this post, we will show a little more about how the process works by showing how iteration fits into the machinery of software development.

The Reason Why

old typewriter

Seth Godin has a post titled The Reason. In each of his examples, Seth asks and answers the reason why we do things that don’t have an obvious rationale.

Requirements elicitation is about asking why. When we ask why correctly, we get great insight, which enables great requirements, which can yield great software. When we ask why incorrectly, we can get a great big mess.

Measuring The Cost of Quality: Software Testing Series

large scale

Should we test our software? Should we test it more?The answer to the first question is almost invariably yes. The answer to the second question is usually “I don’t know.”We write a lot about the importance of testing. We have several other posts in our series on software testing. How do we know when we should do more automated testing?

Project Dashboard Icons

February 23, 2007Communication, Consulting, Presentation, Project ManagementScott Sehlhorst

turn signal traffic light

We create project dashboards all the time to show status, or to give upper management an update. Dashboards and scorecards are great for giving us a “quick view” into the health of a project – they give us a way to drill down. Many of us use the colors red / yellow / green, with a stoplight metaphor. The problem is that some of us are colorblind. Johanna Rothman gives us a GREAT tip. We give you a set of icons / images.

Dashboards and Scorecards

Without going into detail about the differences between the two, they have a common mission: a scannable view of the status of a project. Scannable often means images or colors too, at least in the dashboards we’ve seen (and made in the past). The traffic light is a common metaphor – green is good, yellow is ok but might be going bad, red is bad.

Then someone adds blue. Or orange for “bad, but not end of the world bad.” Sort of like “extra high priority” features.

Rothman On Traffic Lights

Some may use the traffic light model–red, yellow, and green–to denote the project’s state. This model shows today’s state, but it’s hard to see where the project is headed. I haven’t found the traffic light useful, due to the static nature of the assessment and the limit of three levels to denote project state. And unlike traffic lights that automatically change, projects don’t change unless the project manager and the team act to change them. Projects tend to continue in the direction the team is heading.

Sunny Skies or Storms?, Johanna Rothman

We agree, traffic lights are lame. And thanks to Johanna, we now have a much better metaphor.

Weather Reports

This is definitely Johanna’s idea – we’re not stealing it, we’re redistributing it. It goes in the “wish we’d thought of that” bucket. We’ll try and add a little value, though.

In short – weather reports work as a better metaphor both for (current) status, and forecasting. They also allow for more than 3 statuses without breaking the metaphor. Johanna throws up an example with six.

Six may be too many. Suddenly, your audience is tasked with mapping a fairly nuanced break-out against a common metaphor. We think four would be more effective.

weather forecast

We created these using free icons from Ganato, who asked only that they not be downloadable, except from them. Get them there if you want to use them, or search for others. Johanna also points us to a page with a zillion icons, all hot-linked from their respective owners. Don’t take them without permission – but definitely go there for inspiration if you want your own.

The goal is to have a natural and obvious progression of status.

Explaining The Meaning

We could propose definitions for each icon – in terms of what it represents for the project – but we won’t. At some level, the icons need to stand on their own, or they aren’t good icons. If your team needs an explanation, make sure you include it in the scorecard as a legend.

Forecasting

Another thing to keep in mind – the senior manager you’re communicating with has to juggle a lot of information about a lot of projects. And when you have problems, the questions they should ask are “when will it get better?” and “what can I do to help?”

weather forecast

This quick and simple presentation shows where the project was, is, and will be. It presents both position and velocity.

Summary

Thanks Johanna! Stealing this idea. We (all) owe you one.

User Centered Design and Bridging The Canyon of Pain

February 22, 2007Product Management, Software development, Usability, UXScott Sehlhorst

Bridging the Canyon

There is such a thing as too much choice. For new users, too much choice (or control) is too much. For experienced users, too little choice is a problem. Ease of use usually comes from reduced control – but users don’t stay “new” for long. There’s a “canyon of pain” to quote Kathy Sierra in that transition from “new” to “experienced.” We call them “competent” users and we have to help them cross the canyon of pain.

Kathy’s Canyon of Pain

In her article on how much user control is too much?, Kathy talks about how hard it is to make the transition from a new user to an experienced user. We twist that idea into a discussion of feature prioritization. To illustrate her point, Kathy uses a great visual to get the point across.

On the other extreme is Apple’s iMovie. It gives you almost no control, but the payoff is high right out of the shrinkwrap. It exceeds my expectations of pain-to-payoff. But pretty quickly, anyone who gets into iMovie–and is bitten by the movie-making bug–starts wanting things that iMovie doesn’t let you control. So… Apple says, “not to worry — we have Final Cut Express HD for just $299”. The problem is, the learning curve jump from iMovie to Final Cut Express is DRASTIC. There needs to be something in the middle, to smooth that transition.

Kathy Sierra, How much control should our users have?

This is a fantastic visual, and allows us to steal an idea from market segmentation.

Market Segmentation Model

We presented the following chart in an article about how Microsoft is segmenting the market for Visual Studio (a software development environment).

Good Better Best Market Segmentation

Apple’s iMovie is in the “Good” box, and Final Cut Express HD is in the “Best” box. The problem is that users will grow out of the “Good” box, with no “Better” box to move into. Redrawn to illustrate (imagine this is an arial photo of Kathy’s canyon diagram):

canyon of pain

Kathy describes this in the context of moving from one product to another. The same dynamic will take place within a single product as users get more experience. Imagine a product that provides “limited but easy” stuff for new users as well as “full power” for experienced users. How will you get your users across the canyon of pain, when they are ready to start doing more with your product?

Features For Competent Users

A product that is designed with a focus on new and/or experienced users will have this canyon of pain. Competent users need a way to do more than when they were new users. And it needs to be easier than if they were expert users.

By developing features expressly for competent users, you create a bridge across this canyon of pain.

Bridge of Competence

There’s another reason to make sure you build this bridge for competent users.

competent users on bridge

Most of your users will be competent. Users don’t spend very long being new. They quickly want to walk across the bridge, in hopes of doing more. But only a very small percentage will invest the time and energy to make it all the way across the bridge and become experts. Most users will reach a level of competence and stay there.

If you don’t design features for those competent users, they will be in the canyon of pain, instead of enjoying the view from the bridge of competence.

Minimizing the Size of the Canyon

In an earlier analysis of the right number of features to include in a product, we looked at ways to increase the number of features without making the product overly complex.
shifting the curve

The article goes into more detail, but essentially what you are doing is making it easier for users to do more stuff with less effort. This encourages more users onto the competence bridge, and helps them move further along it as well (less effort to become an expert).

By improving features that are already there, you make it easier to get better at using the tool.

improved performance

Conclusion

By improving performance, you raise the utility for the users, ultimately making the bad parts less painful, and the good parts more rewarding.

Both of these approaches focus on improving existing features, versus adding new features. The challenge is to incorporate utility with ROI as part of your prioritization activities.

Business Requirements, Project Scope, and Coupling

February 21, 2007Business Analysis, Product Management, Requirements, Requirements ModelsScott Sehlhorst

train coupling by gregor mima

Robin Goldsmith wrote an interesting article for RQNG about business requirements – what he calls “REAL” requirements. Gathering the right requirements demands more than just effective listening skills, you have to focus on the right problem. Robin brings up a theme we’ve discussed here in the past, and again in today’s article.

Business Requirements

Robin defines business requirements first by what they aren’t. Business requirements are not system requirements, product requirements, or software requirements. He contends that those terms are synonymous. The terms definitely share the same level of abstraction. Product requirements embody an element of design. To define product requirements, you have to choose to address the business requirements with a particular solution approach.

Yes, business requirements are real requirements. And you’ll find yourself nodding your head as you read how most business analysts struggle to define business requirements. They do a good job of defining product requirements, or functional specifications (the system shall…).

The article reads as a very single-customer-centric viewpoint. This is perfect for business analysts. Product managers need to abstract this into market requirements – those things that are valuable to all businesses in the target market. In either case, the points are valid – business value is the goal.

Product Requirements

Here’s a quote from Robin that we completely agree with:

The difference between REAL business requirements and system requirements is not the level of detail. The difference is qualitative. Business requirements are whats. System requirements are design hows. Design doesn’t have to be technical. A product or system is a presumed solution how to accomplish the presumed whats. Whats do not decompose
into hows. Hows are a response to whats.

A little over a year ago, we put it like this:

A product requirements document (PRD) captures the capabilities of the software in order to address the market needs. From these key capabilities comes the design of the software. How do we get from needs to ideas?

This is an ideation task. A product manager must apply high level design skills when writing the specification. Haven’t we said repeatedly that requirements should not describe the implementation or design? Yes. Previously, we talked about the importance of asking why, this is the same issue, approached in the other direction – starting with the why and asking how.

From MRD to PRD, The Key To Defining A Spec

With that in perspective, we turn to project scope creep.

Project Scope Creep

Everyone experiences scope creep on projects. Scope creep can be an opportunity. Even with a good approach for managing project scope changes, it still benefits us to prevent them.

We’ve written about the impact of requirements changes before, as part of our series on the reasons we write use cases. In that article, we mentioned that all requirements change. What Robin points out, that we didn’t talk about, is that market requirements (business requirements) don’t change very often.

He’s exactly right.

Consider the need from our previous market requirements example:

Sole-proprietor restaurants are losing over 5% of their top line sales in food spoilage.

That dynamic isn’t going to change in the near term. The product requirements, once a decision has been made to solve the problem with software are liable to change.

The market requirement:

Sole-proprietor restaurants will reduce the amount of food spoilage by 50%, by making better food purchasing decisions.

Is addressed through two product requirements:

The system shall reccommend ingredient purchase amounts and timing that would reduce spoilage by at least 50% against the baseline.

The system shall allow users to ignore its reccommendations.

Additional decomposition of the problem would represent design or could be considered elements of an SRS (which, being a specification, is either design or requirements – depending upon your perspective).

Coupling Business Requirements To Product Requirements

This is the interesting part – the more tightly (effectively, rationally) the product requirements are coupled to the business requirements, the less change we will have in project scope over time. However – the key is to define the scope in terms of the business requirements (reduce spoilage), not product requirements (reccommend purchase amounts).

Conclusion

If you struggle to define business requirements, and find yourself focusing too much on product requirements, take Robin’s advice (and ours) to heart. Focus on business requirements.

Software Cost Estimation With Use Case Points – Free Excel Spreadsheet

February 20, 2007Business Analysis, Product Management, Project Management, Requirements, Requirements Models, Use CasesScott Sehlhorst

apple technology by diego medrano

We just completed a series of articles detailing how to use Use Case Points for software cost estimation. In this article we have a free MS Excel Spreadsheet for calculating use case points. Download it today to make it easier to do your project cost estimations.

Free Excel Spreadsheet Download

Download the use case point spreadsheet (zipped) for free today from Tyner Blain.

Background

This is the seventh article in a series on applying use case points to create reliable software cost estimates. What makes use case points different is that they allow the project cost estimation to happen much earlier in the process. This cost estimation technique was developed by Gustav Karner for Rational Software Corporation in the mid 1990’s.

The introduction to software cost estimation is the right place to start if you came to this article first. In the previous articles we discussed:

Technical Factors of the Implementation. Characterizing (non-functional) requirements of the software.
Environmental Factors. Describing the team and the process.
Use Case Quantity and Complexity. Representing what the software is asked to accomplish.
Actor Quantity and Complexity. Enumerating the users of the software.
Final Calculations. Doing the math.

The free excel spreadsheet in this article will do the math for you. It provides an easy way to organize (and edit) your estimates, and presents the final calculation results for you.

Using the Use Case Points Spreadsheet

The spreadsheet has five tabs, one for each area of data collection and processing. The tabs map directly to the individual articles in the series (linked above). Each tab also includes links back to the articles for future review.

spreadsheet tabs

To calculate the use case points, you only have to fill in the highlighted (yellow) cells in each tab of the spreadsheet. All of the math is done for you.

UCP Technical Complexity Factors

Enter the relative magnitude of each technical factor. Brief descriptions of each factor are included for quick reference.
UCP Technical Factors Spreadsheet

UCP Environment Factors

Enter the relative weightings of the environmental factors for the project. Brief descriptions are included for reference.

UCP Environment Factors Spreadsheet

UCP Use Case Analysis

Enter the names and complexity of each use case.
UCP Use Case Spreadsheet

Note that the complexity values are selected from a drop-down instead of being typed in. This allows for automatic calculation, just from listing the use cases.

UCP Spreadsheet Dropdown

UCP Actor Analysis

Enter the names and types of all actors that will use the system.

UCP Actor Analysis Spreadsheet

The actor analysis section also uses a drop-down to select the type of actor.

UCP Final Calculation

Return to the final calculation tab at the front of the spreadsheet.

UCP Final Calculation Spreadsheet

All of the work has been done for you. If you want to use a different ratio for converting from use case points to hours of effort, just change the highlighted value.

Conclusion

This concludes our series on software cost estimation with use case points. With this free excel spreadsheet, you don’t have an excuse for not calculating the use case points on your project. The time you will invest is minimal. The value may be substantial.

Software Cost Estimation With Use Case Points – Final Calculations

February 19, 2007Business Analysis, Product Management, Project Management, Requirements, Requirements Models, Use CasesScott Sehlhorst

all the apples combined

The final step in project cost estimation with use case points is to do the math. First you identify the technical and environmental factors that influence your environment and describe your team. Then you analyze the use cases and actors that describe the expectations of the software and who has them. Finally, you bring it all together to do the math.

Background

This is the sixth article in a series on applying use case points to create reliable software cost estimates. What makes use case points different is that they allow the project cost estimation to happen much earlier in the process. This cost estimation technique was developed by Gustav Karner for Rational Software Corporation in the mid 1990’s.

The introduction to software cost estimation is the right place to start if you came to this article first. In the previous article we discussed:

Technical Factors of the Implementation. Characterizing (non-functional) requirements of the software.
Environmental Factors. Describing the team and the process.
Use Case Quantity and Complexity. Representing what the software is asked to accomplish.
Actor Quantity and Complexity. Enumerating the users of the software.

Collecting The Use Case Point Data

abacus

Use the links above the abacus to review any of the calculations that you performed in the previous articles.

In the first step you determined a numerical representation of the technical factors for your software. This is the technical complexity factor, TCF.

In the second step you created a number representing the environmental factors that influence your team’s ability to get the job done. This is the environmental factor, EF.

In the third step you measured the use cases, creating a representation of the quantity and complexity of the use cases that the software must enable. This is the unadjusted use case points, UUCP.

In the fourth step you reviewed the users of the software – both people and other systems. This is the actor weighting, AW. [Note: Some articles refer to this as the unadjusted actor weight, or UAW].

Calculating The Use Case Points

The formula to calculate use case points is described below in terms of the variables from above: TCF, EF, UUCP, and AW.

Use Case Points = (UUCP + AW) * TCF * EF.

The total use case points equals the sum of unadjusted use case points plus the actor weight, multiplied by both the technical complexity factor and the environmental factor.

The next step is to convert this normalized representation of “how big the job is” into an estimate of effort.

Determining Effort From Use Case Points

This is the part where your math becomes an estimate of effort.

Unfortunately, this is where opinions can sneak in when you’re first using use case points. Different experts identify different values to use.

Karner, the originator of the approach, suggests using 20 hours of effort per use case point.
A case-study team, cited by Ed Carroll, found empirical data to support using 28 hours per use case point.
Other estimates range from 15 to 30 hours per use case point, cited by Roy Clem.

Another approach proposed that “complex projects” have a higher conversion factor (28 to 1) than “simpler projects” (20 to 1). The following calculation determines if a project is complex:

For each of the following environmental factors that has a value below 3, add a point.

1. Familiarity with the project.
2. Application experience.
3. Object oriented programming experience.
4. Lead analyst capability.
5. Motivation.
6. Stable requirements.

For each of the remaining environmental factors that has a value above 3, add a point.

7. Part time staff.
8. Difficult programming language.

Add up the points. If you have fewer than 3 points, use 20 hrs per UCP. If you have 3 or 4 points, use 28 hrs per UCP. If you have 5 or more points, restructure the project.

This makes a lot of sense – it essentially says that inexperienced teams will take 40% longer to complete the project. And when there is a significant disconnect (between capability and expectation), the project should be reset – to lower expectations or increase capabilities or both.

Revise and Refine

The key thing to note is that these “generic” effort-to-UCP conversions are a starting point. You have to adjust them over time to improve the accuracy of your estimates. Maybe you will need to rethink what it means to be “experienced,” or just how difficult “difficult” is.

Use Case Points Can’t Be Proven To Work

This actually identifies a weakness in the approach – you can never prove that it works (or doesn’t). Essentially, you have one equation with two unknowns. If an estimate is proven wrong at the end of the project, it could be because the calculation-math is flawed, or it could be because the estimates along the way are flawed. If your estimates prove to be right, it could be because both are wrong, and the errors happen to cancel each other out.

Use Case Points Are Still Valid

Nonetheless, use case point-based software cost estimates are still reasonable. Producing an estimate with use case points will result in a greater likelihood of project success than any other estimate (that I know of) that can be performed at the same stage in the project, with the same amount of data. And the introspective act of calculating UCP at the beginning of a project will help find and avoid costly mistakes later in the project.

Save Time And Effort

[Update: Download our free excel spreadsheet for calculating use case points.]

Flashback: A Year Ago This Week on Tyner Blain [2006-02-17]

February 17, 2007FlashbackScott Sehlhorst

looking in a mirror

Requirements vs. Design – Which is Which and Why

blue team and red team

A classic debate. It comes up often. Unfortunately, it’s a source of confusion that causes many teams to shy away from staffing, creating, or managing any formal requirements processes. There’s a discussion on Seilevel’s forum where this has been brought up again, and it’s shaping up to be a fine grudge match here in Austin. Thanks to Cauvin for calling it to our attention. We can’t let the other folks have all the fun, so we’ll chime in too.

Software Requirements – Process and Roles

Frank Gorshin

Our previous post, Requirements vs design – which is which and why, describes our position on which parts of the software development process are requirements-activities, and which parts are design activities. The debate among professionals about these distinctions is ongoing, and continues in the comments on that post. The length of the debate, combined with the skills of those debating demonstrates that it isn’t a black and white issue.

In this post, we will try and explore the reasons why this debate is ongoing. We will do that by exploring the symbolism of the terms involved, as well as the roles of different members of the software development team.