Estimation is not an exact science because even two projects that appear the same can be subtly different in these areas:
Scope
Integration points, new third party systems that must be communicated with.
Environment (languages, servers, operating systems, people)
Customers, types of user
Developers
Technology. The world moves on between projects.
Agile is not a silver bullet either when it comes to estimation. An agile project still uses approximations same as a waterfall project to ensure the work can roughly fit into the budget.
Before funding is approved
Some high level estimation must occur so that the business can budget for the project cost. Analysis is done by experienced developers who have done similar projects before to work out the approximate number of programming days required to finish the project. This is usually based on formal analysis of the requirements (e.g. Function Point Analysis) or through T-shirt sizing against other projects.
User Story workshops
Agile estimation has additional steps to allow effort to be refined when requirements and use cases are broken up into User Stories during story workshops. Note that this clarification rarely reduces the size of the project, often increasing scope.
For example look at a typical discussion around one high level requirement: “All user interactions will be recorded in an audit log”
Developers: This one is easy - we planned to just add a message to the standard log file every time the user does anything in the application. This will be just one Story Point of effort.
SME: So what columns will we have when we load the audit log into an Excel spreadsheet?
Developers: Uh, so you really need a Comma Separated Value file. That's a bit more work.
SME: Sounds great – where will this audit file be stored? How do we find the file from Excel?
Developers: Uh, we'll it would be a separate file on each of the eight servers. If you need us to collate it all in one file in one location, that's more work too.
SME: Excellent, make it happen.
The developer originally had a complexity of 1 for the requirement, but scope quickly increased to 16 story points during the workshop.
Estimation Workshops
At the end of the story workshops, programmers decide on an effort point system to define the size of each story.
Usually this is an abstraction of days (not days themselves). For example, the simplest of all stories might be used as a guide to indicate one story point, and calibrated at half a day to help users to visualize effort. By the time even the simplest story is finished, half a day has already been consumed in clarifications and desk check changes.
Trap: Never estimate in days on an agile project. It will cause confusion with the business stakeholders and developers when you report that your burn up in 10 days was 13 days. It is far better to say “we completed 27 story points of work in 10 days”.
There are many online blogs already on the process of agile estimation, estimation poker, story points, inceptions etc. so there is no need to repeat them here. But I can offer this advice:
Tip: If a User Story has a lot more lines of text than other stories, it may be a clue that it will take longer to implement than you think.
Story Ordering Workshop
All stakeholders gather and spread the story cards out on a large table to order them - or using software tools, but doing it on a PC is less fun. They are then sorted in the order they will be developed, taking into account dependencies between tasks. For example the screen stories that depend on another back-end integration story will be placed further down the list.
