If you are like me, then you have given a majority of your friends and family a gift card for various occasions.  I actually got into the habit of grabbing a gift card every time I was at the grocery, just so that one was available when I needed it.  Of course, there have still been countless times where I had to quickly run out and get a gift card for an occasion.

Recently, I discovered CardNow.  For a small fee, they ship a set of gift cards with no balance to you.  Using their app, you can reload the gift card with a given amount.  Start at $4.99 for 10 gift cards (2 sets of 5), this seemed like a good and cost effective solution (cost of gas and time spent waiting in line to purchase a gift card).

Pretty straightforward, but is it worth it?

Pros

• Easy to load gift card value
• Convenient
• Cost effective, when you compare the amount of time and gas it takes to purchase a single gift card at the store.

Cons

• Limited selection (See here)
• App does not integrate with ApplePay (as a new application, not quite ready to save my card information)
• Minimum card balance of $25 (Still will have to go out and grab a pack of $10 Starbucks Cards)

Overall, for someone like me, this is a great addition to my collection of gift cards for all occasions.  Let me know your thoughts?

“How easy is it to build a QR Code Generating Website?”
​
After 3 weeks adhering to California’ Shelter in Place mandate, this message from a colleague was refreshing. I quickly responded to him saying that it was relatively easy to build. In the back of my head, I was thinking that this would be a great example to build upon my Automating Agile presentation from 5 years ago (https://youtu.be/kBGxM5M49TI)

In the new version, I want to apply the lessons I’ve learned over the course of my career with some of the technology and tools that I’ve become proficient in. There are three important lessons that I want to incorporate as I build the QR Code Generating Website.

Lesson 1: Traceability
Years ago, I worked at a great start up that eventually went public. It was there that I learned the power of Behavior Driven Development (BDD) and the importance of tracing functionality to business requirements. As part of my responsibilities, I was the interface for the auditors to review product requirements, test cases/reports and defects. Traceability was a big part of my life then.

Lesson 2: Accountability
As my career matured, I began going up and down the “silos” of the various development organizations to ensure that code delivered to me was done with high quality. A lot of that time was spent reviewing basic unit, integration and functional tests. Eventually, it would include reviewing performance and security testing results. Thanks to tools like Jenkins and Sonar, I was able to do a majority of my reviews in a single application. This helped make my traceability efforts accountable for everyone on the projects.

Lesson 3: Manageability
Managing all these software development activities required the need for collaboration tools like JIRA. Out of the box, JIRA is a great tool to manage your day to day tasks. If there is a need to provide information in a ticket that cannot be accomplished with the existing set of fields, JIRA provides the capability to add custom fields to a ticket. This has been both a blessing and a curse to the agile process (A topic for another time). The other challenge, which JIRA can handle well, is actually managing the requirements that make an epic/story/task become a reality.

Getting Started
After creating a project in JIRA for the QR Code Website, I want to focus on how my epics and stories would help me to build the website while still accomplishing my traceability, accountability and manageability wish list. In short, I want to demonstrate that:

• The business requirement is clear
• The evidence of testing is clear
• The completion of a story/epic is clear
• The functionality of the story/epic in production is clear

The Epic
My goal is to have a basic functioning website, nothing very fancy. In the spirit of the feature file, I used the description field of the JIRA ticket (Epic) to create the first epic:

In true BDD style, I placed in the description field the standard narrative outline:

As a <person/role who will benefit from the feature>
I want <the feature>,
So that <benefit or value of the feature>.

Instead of customizing JIRA, I decided to include the acceptance criteria in the description field as well. More on that in a later story.

​One thing to note about the acceptance criteria is that I did not follow the convention of using the Given, When, Then pattern. The reason is that it will be covered in the feature file that will drive the automated tests to validate my epic. Instead, I’ve mapped the acceptance criteria to the two scenarios in my feature file. The scenarios contain the Given, When, Then format.

The format of the JIRA epic, along with the feature file, highlights the traceability between the requirements in JIRA and the tests written in the feature file.
Accountability is handled by the use of the pronoun, ‘I’. When the sprint team reads the epic and feature file, the use of the pronoun ‘I’ will make the team accountable in completing the epic. In this case, the team consists of me playing the role of Product Owner, Developer, and QA. Therefore, I will be accountable for the entire project.
Considering that this is a small epic, managing this effort will be easy. Next time, I’ll break down the grooming of an API story to support this epic, diving further into defining the acceptance criteria and how it translates back to tests to achieve the finish product in BDD fashion.

Last year, I had this idea of seeing if I had enough change to build a pc from scratch.  Unfortunately, life got in the way so I never had a chance to follow through.  This year it will be different.  Monthly coin drops to my local Coinstar should help me keep things on track.

So for January, I cashed in $29.28 for an Amazon gift card.