Point Case Estimation techniques work for Agile Projects.
One of the areas that Agile methodologies suffer in, is a perception war that is built on the premise that ‘estimation’ comes with the risk of project approval and kick off via techniques such as velocity. Some believe that to be truly agile there is no up front estimation, only estimation as expressed through the ‘iterations’ and using ‘velocity’ to measure.
One question I keep hearing over and over again is:
"what do we tell our clients when they insist on having some kind of up front estimation on how long the project will take to complete?"
Some clients will NOT move forward with any commitment at all until they have
some form of an estimate, so what do I do now? Don’t get me wrong, I am not advocating fixed priced contracts here (oh dear me no - that will be a subject for a later post), what I am offering here is the idea that initial requirements gathering (the functional & non functional) can be captured by using Agile ‘User Stories’ and plugged into the point case estimation formula and subsequently used to provide the client an estimate that they wouldn’t otherwise agree to progress the project without. Let me give you a real world successful example of a two week effort in project scoping and estimating.
The User Stories
In week one, our Architects sat with the client subject matter experts and internal development team and discussed the nature of the system required. The conversations revolved around both the functional and non-functional aspects of the system and included our architects modelling the domain.
In week two our Architects set about documenting the notes and drawings from week one and converting that information into our organisations internal representation of a user story. The organisation I work for practices it’s own hybrid ‘Agile’ methodology, incorporating practices from XP such as User Stories, Pair Programming, Continuous Integration, regular release to the stakeholders and other attributes successfully employed in the past by various members of our team.
Granularity of a story
The User Story itself is fairly coarse grained compared to some anecdotal comparison to what I hear from people in the industry and from my reading in the blogsphere; it does include the textual description of the story however also includes a Use Case Diagram to express the story in graphical form. We find the Use Case diagram useful to communicate parts of the system both to developers and the business .Each story is also accompanied by what we refer to as the Detail Table, which is primarily composed of aspects on each story that complete as much detail about pre and post conditions, architectural context, inputs and outputs, success and fail scenarios and more. Figure 1.0 below is a freehand drawing of a typical User Story without the detail table.
Figures 1.0 & 2.0 - The User Story and Detail Table
The Point Case Estimation Tools
Point Case Estimation formula appeared in the early nineties and provides estimations for predicting the duration of producing software components and applications. For a detailed explanation on the method please read further using these resources.
http://tynerblain.com/blog/2007/02/12/software-cost-estimation-ucp-1/
http://tynerblain.com/blog/2007/02/19/software-cost-estimation-ucp-6/
Also you can download a spreadsheet that performs the calculations to provide your estimate from here.
My personal experience with this method has been very satisfying, it allowed us to set our engagement with an initial estimation and the project estimates have more often than not turned out to be almost spot on with the actual deliveries. Bear in mind that the estimate should be treated as exactly that - an estimate (my group charges time and materials) and is not recommended as a instrument to provide fixed price bidding!
