Skip to main content


Clear Salesforce Requirements = Clear Defect Tracking

Break these rules and suffer the consequences!

If you do not have clearly understood requirements and logged defects, you will spend countless hours debating over what is in scope, what is not in scope, what defect should be fixed and what defect should be backlogged and pushed to a later sprint.

One defect, discovered recently on a project, was estimated at taking one hour to fix. However, because several of the requirements were loosely worded, we debated on when and how we should fix the defect and if it was required for go-live or not. Spirited debate ensued and we found ourselves stranded in the grey zone of doom. Fortunately, an experienced project manager gave the green light on the fix and we were able to resolve the defect successfully. Applause and cheers!

De-Squish the Defect

I learned a valuable lesson on a recent Salesforce mobile app project I joined two weeks before QA testing was to begin and four weeks before go-live to select retail stores. The mobile team had worked for more than a year to design, develop and deliver the Salesforce Mobile app to in-store sales reps. There were many complex API calls being made to product databases with delivery dates and accuracy in availability was critical. This was not your typical food truck mobile app taking a ten-dollar order of street tacos and guilt-ing the customer into a 20% tip upon checkout. The average order for this client was several thousand dollars with multiple payment types including financing and multiple delivery options of products.

I spent the first day with the transitioning LBC, Lead Business Consultant, on the project going through the many logged defects and it was clear to me that while many were very easily understood and could be addressed in the two weeks, there were some defects that were very “squishy.” In other words, they were very subjective and unclear about what needed to be addressed and more importantly how to fix the defect and be done with it. One defect in particular caught my attention and it read as follows:

“There is a noticeable performance issue.”

Imagine your significant other leaving you a note on the counter with those exact words. Ugh!

As a member of the male gender group I would immediately jump to, ‘did I forget to take out the trash, pay the bills, pick up our tween from a goats-and-yoga class, or worse…”

It’s our duty when logging defects to de-squish the defect. However, that might be a challenge if the original requirement was squishy as well. In this performance issue defect there ended up being dozens of chatter posts about the performance issue and trying to clarify and define it. We began timing page loads, API call-out times, shopping cart loads of all sizes from two to forty-two individual line items–all trying to resolve and close the performance issue defect. At the time of this post, that noticeable performance issue defect is still unresolved–Double Ugh!

Defect Logging Examples

Here are examples of good defect logging:

  • When I choose a product from the Automobile Catalog such as All Weather Floor Mat and then select the shopping cart of the customer, the Actual Price of the Product displays incorrectly. The product item shows a price of $100 in the catalog but the price in the shopping cart displays as $89.95.
  • When viewing the shopping cart of a customer, I select Proceed To Review and select the Accept Terms and Conditions signature field. When I sign my name and touch the Accept button I get an error screen in red that reads “API connect error: Zip Code not Valid”
  • When I touch Proceed to Payment in a customer’s shopping cart, I select the Pay By Credit Card radio button. The amount field is grayed out and I cannot enter an amount to process.

Here are Squishy examples of defect logging: Use at your own Risk!

  • The UI has issues
  • The shopping cart is not right
  • I’m getting lots of errors when I try to add a new record

Rules to Live By When Logging Defects

  • Be as descriptive as possible
  • Share where you were before and what path you took to get there
  • Name buttons exactly if you can
  • Take screenshots or video captures
  • Add date/time of incident

IN CONCLUSION, (that was my HS English teacher shouting in my ear) regardless of when you join a Salesforce project, bring clarity to everything you do as you contribute to the team. Remember, this is not math, things are never perfect, but if you focus on being clear and not being squishy, your colleagues will thank you and management will sing your praises. In the key of C Major, please.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Rodney Henson

More from this Author

Follow Us