[tweetmeme source=”aabdulmoniem” only_single=false]

Today, our product owner has sent me a document which contains some bugs as he said. I have opened the document to see what are the problems with our system, but I have found that most of the notes which were named bugs simply not bugs but they are new features.

I have decided to hold a meeting with him afternoon to discuss him about those notes. I told him: “These are not bugs, they are new features.”. He said sadly: “No, No … They are bugs. I didn’t expect all these notes. Why this feature is like this? and why the other feature is not working as my expectations … etc.”

The problem I am facing here is just we are not meeting his expectations, and the cause is very obvious, he didn’t write his expectations about each feature. In other words, he didn’t write acceptance criteria for each user story (Scrum is our process).

Rule of thumb:

Always, ask your stakeholders about their acceptance criteria before going to code.

Let’s take an example from Software Estimation book by Steve McConnell to see what I am talking about here:

Suppose you’re developing an order-entry system and you haven’t yet pinned down the requirements for entering telephone numbers. If I didn’t ask the product owner about what he is expecting while entering telephone numbers, I may implement it in another way which will not meet his expectation. Some questions may be:

When telephone numbers are entered, will the customer want a Telephone Number Checker to check whether the numbers are valid?

If the customer wants the Telephone Number Checker, will the customer want the cheap or expensive version of the Telephone Number Checker? (There are typically 2-hour, 2-day, and 2-week versions of any particular feature—for example, U.S.-only versus international phone numbers.)

If you implement the cheap version of the Telephone Number Checker, will the customer later want the expensive version after all?

Can you use an off-the-shelf Telephone Number Checker, or are there design constraints that require you to develop your own?

How will the Telephone Number Checker be designed? (Typically there is at least a factor of 10 difference in design complexity among different designs for the same feature.)

How long will it take to code the Telephone Number Checker? (There can be a factor of 10 difference—or more—in the time that different developers need to code the same feature.)

Do the Telephone Number Checker and the Address Checker interact? How long will it take to integrate the Telephone Number Checker and the Address Checker?

What will the quality level of the Telephone Number Checker be? (Depending on the care taken during implementation, there can be a factor of 10 difference in the number of defects contained in the original implementation.)

How long will it take to debug and correct mistakes made in the implementation of the Telephone Number Checker? (Individual performance among different programmers with the same level of experience varies by at least a factor of 10 in debugging and correcting the same problems.)

As we can see, some questions like this will give us more explanations about what he wants? and the first dialogue will not happen again if we meet what he looks for.

A really good lesson you have to learn and to teach.