Estimation by stuffing things into boxes

March 17, 2014

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:

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

Experimental create open position
Experimental list positions
Simplified create open position
Simplified list positions
Complete create open positions
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.