Living in the Tech Avalanche Generation

Recently our team has been engaged in developing a highly scalable batch processing system, which to be fair didn’t require much beyond a fairly simple User Interface with few screens. Given our choice of WPF as the technology to build the presentation layer, we decided to extend our curiosity in SketchFlow and put it to the test in a real live project.

So, off we set and created our prototype and when completed, sent it on to the stakeholders to cast their critical eye upon it and provide feedback using the SketchFlow players tools for capturing feedback. I must admit that I wasn’t convinced that our users / stakeholders where going to be particularly enamoured by the experience but I am happy to say that I was wrong- so incredibly wrong. Whilst developing the prototype I found myself continually applying my own biases toward the tool and they were such that I was developing an opinion that SketchFlow’s feedback mechanism was a little too simple and perhaps even ‘clunky’ to provide them with an experience that they would consider productive or enjoyable. However, the feedback came through very swiftly and along with it an enormous endorsement of the process, tool and the whole experience.

These user / stakeholders are used to defining and or changing a proposed UI layout in well known visual design applications (unnamed) and feeding those design documents accompanied with text documents (for annotation) to the software team for consideration. These documents would bounce between parties until a finalised design had been settled upon.

This time, upon having been supplied feedback via SketchFlow, they are reporting a significant amount of saving in time dedicated to the process and they are attributing that time saving entirely to the ease of use and functionality of SketchFlow. Now it’s early days yet and I don’t want to get carried away until we get a few more iterations into the process, however I am feeling pretty excited when our users come back with such positive feedback in their experience of the whole development life cycle.

And there I was, ready to put the kybosh on the idea. I cant argue a case when the business stakeholders show you nothing but thumbs pointing in an upward direction.

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!

We at ITR have been using Use Case Point Estimation now for about 18 months and we are finding it to be very accurate and that it fits our business model nicely too. We use this technique to provide clients with indicative first up estimates (even though we work to time and materials), enabling them to come to some conclusion as to what features to build into their product at a particular juncture in time.

I have found this technique to work so well in fact and to blend so nicely with our agile practices, that I am going to move the estimation formula into an ASP.Net application and make it available from our Web Site when it goes online shortly. The application will include the ability to upload user stories (with attached Use Cases in XMI format).

I will post again soon when it’s available.