When we last left the “Customer” we got a clear perspective on “What” the customer wants in this application. And to make the analogy we have a full Cart. However, We have not defined what kind of horse we are going to need to deliver the “Cart”. My first blog identified the building blocks we would need but it was very high level. Duplo blocks and Lego blocks are both blocks but they have distinct differences. The obvious difference is their scale followed by the variety of pieces available in each type of block. And the point here is now that we are starting to “get serious” about making this application more detail has to be added to the picture. Agile says only make what we need when we need it.
As the Architect I need to block out the design components and set some expectations for it. Also since I am new to this type of development I am going to have to do a couple of “Spikes” (stories that prove concept). As the Architect I know the customer has not specified user stories that will “pull” the cart. Couple this with the Agile principles of only developing what you need when you need it and it is a wonder we get anything done as the “actors” clamor for results.
Going back to the Customer we ask which User Story is most important. And the Answer is “Backup Collection”. I have also asked the Customer what the success criteria would be for this story. Of all the scrum teams I participated on this seems to be the weakest link in the process. Product owners really need to push the customer here because most customers will want to find the easy way out. Success is when it works. I.e. “bring me a rock” and if I like it then it is a success is not good enough. But here is the thing, pushing your customer to think more specifically about this will define your functional tests. A good tool for success or acceptance criteria is the use of “Gherkin” statements. They provide clarity for the developer and it helps the customer to think specifically about their application.
Gherkin arose from a development language called Cucumber which is very useful if your team is taking a “Behavior Based Development” (BBD) approach. I am not going to use that methodology but one very useful thing that came out of this approach was Gherkin statements.
Looking back at my second blog post What the Customer Wants I realized most of the way through it that I did not properly format the User Stories and I indicated I would “fix” it in a future post. Well, that may occur over several posts as I will fix it for specific user stories when we come to them. For now I have rewritten the “Backup Collection” user story as
As a Wine Collector I need an offsite backup of my wine inventory so I will be able to make an itemized report for the insurance company when disaster strikes.
I have also created a couple of Gherkin statements for the Acceptance Criteria and it is of the form “Given <a state of the application> When <an event or action is taken> Then <an expected result occurs>”. This can be expanded with more “And, When, Then” clauses if they are happening at the same time. The selected user story Acceptance Criteria follows below:
Given a myWineDb data store. When a change occurs. Then the app will back up the data store to a cloud based file store. And the app will have a visual indicator to that effect
Given a myWineDb application When the local and remote data stores are in sync Then the application will have a visual indicator to that effect.
Because the app does not exist yet there are a lot of Tasks that need to be defined and organized on the backlog. Normally, the Customer would decide the order of importance for the smaller tasks but early on in the process the Architect is going to have significant input on how we will “build the horse” to a point that this epic story can be delivered.
Next we will identify the tasks and start working (finally).
My WineDb Journey 