Login   I   Sitemap   I   Contact Us   I   Sales: (US) 1-866-468-5210   (EU) +49-711-67400677
Intland Software - Collaboration Begins Here
Download or Try the fully functional version of codeBeamer. It's free, simple and secure.
codeBeamer is the award winning Collaborative Application Lifecycle Management (ALM) solution for distributed software development.
Project management, wiki, document management, issue tracking, ITIL, continuous integration, version control, source code analysis and forums.

Links

Feeds

Editor Menu

When is a feature done?

I was just recently reminded of a debate that I seemed to get into very frequently back in the days I was a Product Manager. It quite often came up in a status meeting when we were going over the progress of the project. It always came up when we would have our release readiness meetings for a product. As we would work through the traceability matrix either seeing if a requirement had been implemented or if a feature was ready for release in the product, a debate would start as to if the feature was "done".

More often than not the development team defined it in binary terms: was it there or was it not; whereas, I had a scale. The binary assessment was one of existence. If it showed up in the product it was done. My scale assumed existence but then assessed the quality and usability of the implementation: was it efficient, was it intuitive to the user, and was it the best way to do it? I took the role as the customer advocate seriously because I knew that not only would it make the software sell better but also it would reduce the problems that me and the team would need to deal with later. Of course the ultimate would have been requirements that articulated quality and usability in a form that was binary. I learned that later.

I had a list in my mind that I always meant to write down - my version of these "universal qualities or attributes". Recently, I came across a fascinating hierarchy by Kathy Sierra, of "Head First" fame, that really summarizes what I was trying to do and say back then. It is a knock-off of Maslow's Hierarchy of Needs except she has called it the "User Hierarchy of Needs". It works in the same way Maslow's did i.e. you must satisfy the lower need before being able to move on to the next more satisfying level. Here it is.


  1. Functionality - Does it do what I need?
  2. Correctness - Does it do it correctly, without a bunch of bugs?
  3. Learnability - Can I learn it quickly? Is the manual good?
  4. Efficiency - Does it let me do what I need without long workarounds?
  5. Usability - Is it user-friendly?
  6. Intuitiveness - Does it feel natural and "doesn't make me think"?
  7. Flow/Enchantment - Does it keep me fully engaged, where the world drops away?

Keeping these in mind when writing or reviewing requirement specifications or when writing code will dramatically improve any application. One of my favorite questions that I would pose during those debates was "imagine if you were the customer using this application what would you think?" This hierarchy is a great checklist in that same spirit.

As I look back, I still wonder how I never found the time to write these down given how important they were and are. It would not have taken any longer to document them than it did to have the same debate we invariably got into ;)

Comments:

Post a Comment:
Comments are closed for this entry.