-
Get a monthly update on best practices for delivering successful software.
A few years ago, a friend of mine asked me to help him estimating the conversion of a client/server application to the web. He came armed with a spreadsheet of features, I came armed with Ibuprofen and a red pen.
My usual approach to estimating involves breaking down the features into things that can be implemented by a pair of developers within a two week period. I give these a complexity factor of 1-5, then run them through an empirically derived formula to come up with an estimate in terms of person-iterations. (It's actually a little more complicated than that, but this is the main effort). Getting the count and size of these mini-features right is the key aspect of this technique. His spreadsheet had almost 300 features listed, and so we settled in for a day of fun.
After feature number 30, I turned to him and asked, "don't you have any business features in this thing?" His features were not about business use cases -- editing or updating some business entities, performing a business transaction -- they were instead about how this web application could function just like the client/server app it was replacing, i.e. "the administrator will be able to update the checkbox cascading order via the module screeen..." Blech! So next we trimmed out all of the UI features which cut the volume of features by 80%.
As it turned out, my friend had been so focused on UI specs that he forgot some critical business user stories. After adding these we were still down 70% of the feature volume. The trimmed features looked a lot like the specs for a web application framework, and not a very good one.
At the end, my friend asked me what he should do with those UI features we had trimmed out. "Delete with extreme prejudice," I told him. "I wrote that application in 1996 and made all of the mistakes you were about to make."
Lesson: If you're renovating an old application, go back to the business requirements and let the application and user interface come as a natural part of the development process, otherwise you will find yourself spec'ing out a web framework circa 1997.
Related posts:
Topics: agile, Estimating, Requirements, User Experience Design
[...] moment to try and make my point a little clearer. Bugs and estimation have been a hot topic with us lately, but interestingly we are all working on different projects and actually have a slightly different [...]
Pingback by Agile Ajax » Bugs can’t be estimated » Pathfinder Development, Tuesday, May 5, 2009 @ 11:59 pm