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!
3 Comments so far
Leave a reply
Simon,
Thanks very much for the great, practical example! I’ve spent the last few years figuring out how to combine a solution for determining, communicating and managing business goals with the obvious execution benefits of developing with an incremental methodology.
The two areas where companies struggle most are in estimation and institutional memory.
Estimation comes into play in two ways - first, as you mention, in green-lighting a project. Second, in driving prioritization (which should not be based solely on value, but also on cost (via estimates) to maximize ROI.
Institutional memory is simply a way for the company/client/business to remember “why did we do that?” down the road. If you’ve got the same people, and they remember, great. But what about 2 or 3 years later, with an average of 30% turnover in IT (don’t know if that number is still current, but it used to be). If we chronically forget why we added a particular capability (or for whom we added it), we risk dropping it. Best case, we re-invest in re-discovery of what we’ve forgotten.
Regardless, great story, and thanks very much for the links! Personally, I’ve still found use case points (or use points, as you’ve re-branded them) to be the best low-overhead / very-early estimation technique. They are a good tool to use exactly where you used them.
Thanks again, and keep it up!
Scott
I am creating an application that will take XMI (UML Diagrams serialized as XML) as inputs and allow users to automate estimations much as they would do manually with the Excel spreadsheet. I will be shore to let you know when it’s done.
Thanks
Simon
[...] was going to use Use Case Estimation (a subject I have blogged about in the past) as side project to allow my WFP and XAML skills really start to develop and take [...]