so much I thought I would steal it.
I’ve (sic:
Johannes Brodwall)
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.
