I’ve started using an approach for software project estimation that so far is proving to be fairly transparent, quick and reliable. I’ve observed that within a reasonable degree of variation, most teams seems to complete about one “user-relevant task” per developer per calendar week.

There are so many theoretical holes in my argument that there’s no point trying to cover them all. The funny thing is that it seems to work fairly well in practice. And to the degree that it’s dirty, it’s at least quick and dirty. The only thing I will address is that one of these “user relevant tasks” is smaller than a typical application feature.

Most importantly: Most teams never get it right on the first try. Or they spend too long gold-plating everything. Or both.

This article shows an example of estimating a fictive project: The Temporary Staffing System.

The high-level scope

Let’s say that our organization has come up with the following vision:

For a temporary employment agent who wants to match candidates
to client needs, the Temporary Staffing System is an
interactive web application, which lets them register and
match candidates and positions. Unlike competing systems
this lets us share selective information with our clients.

We come up with the following flow through the application:

1. A new company wants to hire a skilled worker for a temporary position
2. Administrative user adds the client details to the system
3. Administrative user adds client logins to the system
   (perhaps we also should let the clients log in with LinkedIn etc?)
4. Client logs into the application and completes new position
   description, including skill requirements
5. Temp agency adds a worker to the system
6. Temp agency proposes the worker to a position registered by a client
   (in the future, the worker may register themselves!)
7. Client gets notified of new proposals (via email)
8. Client views status of all open positions in the system
9. External to the system: Client interviews candidate, request further
   information and makes a decision whether to hire or not
10. Client accepts or rejects the worker in the system
11. As worker performs work, they register their time in the system
12. At the end of a billing period, the system generates billing information
    to accounting system
13. At the end of a salary period, the system generates salary information
    to the accounting system

Some of these steps may be one user story, some may be many.

The top of the backlog

We choose some of the most central parts of the scope to create the beginning of the backlog. In order to accommodate for the learning as we go along, the first draft of our backlog may look like this:

1. Experimental create open position
2. Experimental list positions
3. Simplified create open position
4. Simplified list positions
5. Complete create open positions
6. Complete list positions

An “experimental” version of a story is a functionality trivial version that touches all parts of the technology. In the case of these two stories, perhaps we have the application leave the logged in client as a hard coded variable. The story may only include writing some of the fields of the positions, maybe only title and description.

The Simplified version may add more complex properties, such as skills from a skill list or it may add filters to the list.

The complete version should be something we’re prepared to put in front of real users.

By revisiting a feature like this, we have the chance to get the feedback to create a good feature without gold-plating.

Continuing the backlog

We add enough of the other stories to the backlog to cover an interesting part of the scope:

• …
• Basic create client account
• Complete create client account
• Basic login admin user
• Basic login client user
• Complete login client user
• Basic add worker
• Complete add worker
• Basic propose worker for position
• Complete propose worker for position
• Complete confirm worker for position
• Basic enter timesheet (in this version temp agency enters on behalf of worker)
• Experimental billing report
• Basic billing report
• Basic salary report

This functionality should be enough to have a pilot release where some clients and workers can be supported by the new system. Or we may complete the backlog with complete versions of all functionality, worker login and perhaps a polished version of a feature or two.

Adding the non-functional tasks

There are some tasks that we want to plan some extra time for. I generally find that many of these tasks are tasks that customers understand quite well:

• …
• Attend training on CSS (the team is rusty in design skills)
• Basic layout and styling of web pages
• Complete layout and styling of web pages
• Polished layout and styling of web pages (they want it really nice)
• Locate slowest pages and make some performance improvements
• Deploy solution to target platform
• Deploy demo version to wider set of stakeholders
• Deploy pilot version
• Exploratory test of complete flow

Planning the project

In this example project, we have five team members plus a coach/project manager on half-time. Since our team will be working in pairs, we want to work on three functional areas per week. This way, we can avoid huge merge conflicts. The team agrees to plan for five stories per week, but only three the first week, because things generally go slower. Here is the top of the completed backlog:

• Week 1: Experimental create open position
• Week 1: Experimental list positions
• Week 1: Attend training on CSS
• Week 2: Simplified create open position
• Week 2: Simplified list positions
• Week 2: Basic create client account
• Week 2: Basic layout and styling of web pages
• Week 3: Basic login client user
• Week 3: Deploy solution to target platform
• Week 3: Basic add worker
• Week 3: Basic propose worker for position
• Week 3: Basic enter timesheet (temp agency enters on behalf of worker)
• Week 4: Experimental salary report
• Week 4: Complete layout and styling of web pages
• Week 4: Complete create open positions
• Week 4: Complete list positions
• Week 4: Deploy demo version to wider set of stakeholders
• …
• Week 6: Exploratory test of complete flow
• Week 7: Deploy pilot version

Presenting the plan

Working through the list gives us a complete timeframe of just over 6 weeks for full feature set for the pilot release. To cover realities of life, we probably want to plan for at least one week of slack or even more, depending on the strength of our commitment and the consequences of being wrong.

This gives a plan indicating 7 weeks times 5 people at 40 hours per week plus a 50% project manager at 20 hours per week or a total of 1540 hours.

I generally find that after a pilot release (or even before it), things change a lot. So I don’t invest much time into planning this.

Tracking the development

The true strength of a plan like this appears when you start running the project. Each week, the team will report on which stories they completed. This allows us to adjust the plan to actual progress.

On the flip side, the weekly planning comes down the team and the customers agreeing on the definition of a story. The vagueness of “basic add worker” is by design! But the team should agree on what they mean by “experimental”, “simplified”, “basic”, “complete” and “polished”.

Conclusions

In this article, I have showed a quick and accurate way of coming up with a project forecast, complete with time and cost estimates. It’s easy to see and react to deviations from the forecast.

A few critical critical observations support this methodology:

• I never believe a developer estimate other than “by the end of the day” or “by the end of the week”. (Don’t talk to me about hours!)
• Estimating in hours is a silly way to get to project costs. Any hour-based estimate is always prodded and padded before magically turning into cost. Instead, estimate number of features, feature per week and cost by week.
• Visiting a feature multiple times lowers total cost due to less gold-plating and investment of in poorly understood areas. It also improves the success of the final feature
• The ambition of a feature (that is, how many times we will visit it) is a more reliable indication of cost than developer gut feeling

I’ve left many questions on the table, for example: What about architecture? What is meant by a “simplified” user story? How to deal with deviations from the forecast? Feel free to grill me for details in the comments to the article.

“So what will it cost?” Using this simple method to lay out your project forecast week by week, you can give a better answer next time someone asks.

I’ve previously talked about the idea of shifting from estimates to budgets.

The fundamental point of this article is that it’s more useful to control costs than to predict costs.

The problem of this argument is whether it’s possible to develop software in that way. How will the relationship between the developer (or supplier organization) and the customer (or the customer organization) have to change? Is this a chance we’re able to make?

In my popular style, here is a typical dialogue:

• Customer “… So, we’re going to change the patient appointment request form to include the social security number of the user and use this field in all the relevant processes. Can it be done in two weeks?”
• Developer “I believe so. But we probably can’t automate everything in this case.”
• Customer “That’s all right, just do what you can within that timeframe”
• A week passes
• Developer “I’ve done a lot of work, but I haven’t got anything to show you yet.”
• Customer “You’ve spend half the budget, and we’ve got nothing to show for it? That’s it, I’m pulling the plug. Throw away what you’ve done and let’s work on something else.”

Meanwhile – in another universe

• Developer “Let me show you: I’ve got the field in the appointment request form and it’s also displayed when looking at the appointment details. I’ve tested this automatically and manually, and deployed it on the acceptance test environment.”
• Customer “Great work so far. These are the next improvements we want (in order of importance): Make sure that non-privileged users never see the number, include the field in the invoicing process and make the input form validate the social security number. Then integrate the field in other processing as well.”
• Developer “Sure thing. I’ll talk to the users for details.”
• Another week passes
• Developer “I’ve fixed the security issue by checking the user privilege before displaying the field. I’ve also included the field in the invoice process. But I didn’t have time to add the validation. Everything is tested, of course.”
• Customer “Great! We’ve spent the budget, so we’ll stop there. The validation is actually pretty important, so I’ll considering adding a new user story to the budget for that.”

In this story the developer had to produce a minimum story before spending half the budget. This ensures that we get something when the budget runs out. The developer had to finish one expansion of the user story at a time until the budget was expended. And then stop! When the customer wanted one of these sub-features bad enough, he had to create a new user story, thus expanding the scope of the project.

Can we learn to work in this way? As a developer, can I learn to organize my work so that I have something to show for it after just half the budget? Can I learn to keep track of the time I spend so well that I know when I’m over budget? And can I have the discipline to stop once the budget has been spent? As a customer, can I learn to accept that the developer will do the best he can within my budget and accept that?