A long time ago, in a galaxy far, far away...
...Wait, wrong movie reference.
This is another post from the Gitfather, your all knowing and loving code zaddy.
I wasn't always the Gitfather though...
Before my current iteration as a Gitdad, I was a Business Analyst.
A strange role at the unholy intersection of code and clients.
Sometimes also called a "Product Owner" (and hopefully rarely also a Project Manager), the Business Analyst lives at the complicated marriage of business and technology, marrying the technical with the non-technical.
(They also get confused with Business Intelligence Analyst who actually analyze data sets, but that's a topic for another time...)
To be more blunt, I basically took an idea from non-technical ask ("we want this button to turn blue!") and broke it down into technical requirements that Developers could use.
Story Mode
While BAs do a variety of different jobs, one of the most important jobs was writing User Stories, which is essentially an update request to Developers.
If you're not familiar with what User Stories are, they basically are a summary of what a development update should do.
For instance, a ticket with user stories would probably look like this:
- As a user, when I click on a button, it should change color from red to blue.
- A search feature allows a user to hunt among various invoices if they want to credit an issued invoice.
- The system sends a confirmation email when a new user account is created.
In essence, a user story should have a: beginning and an end. When something happens, this should happen.
Turn Up the AC
User stories are also usually accompanied by acceptance criteria which is a fancy term for "what completes a user story?"
Acceptance criteria are the lowest-level functional requirements.
So, in the above examples, the acceptance criteria for the user story might be:
- GIVEN I am on the Home Page with a Button, WHEN I click on the "Return Home" button, THEN the "Return Home" button background color renders from red to blue.
- GIVEN I am on Google, WHEN I enter an input into the Search bar, THEN I am able to view and browse results based on my search input
- GIVEN I am not a registered/authenticated user, WHEN I register with a new account, THEN I am sent a confirmation email confirming my successful registration.
You'll notice that the acceptance criteria are structured using a "GIVEN... WHEN... THEN" statement. It sounds more "code-y", more developer focused.
It also sounds kind of like what the user story said, but in much more specific terms. This lays out a clear roadmap for what the Developer must complete in order for the update to be done.
Acceptance criteria and user stories all "ladder up" to one big project, usually called an Epic, which is the over-arching, bigger software update that is driving everything.
One Ticket To Rule Them All
Epics, User Stories, and Acceptance Criteria are major points of the Agile Methodology of Software Development.
While there have been literal textbooks written about Agile, the TL;DR is a project framework of completing software updates into manageable chunks.
There are many other methodologies, but, in my humble opinion, Agile is the most commonly used (and ripped off...looking at you Waterfall...).
Basically, breaking big updates into medium ones and those in to smaller ones, and so on, until you get to what would complete the update. And then working on those updates in 2-3 week "sprints" until the whole thing is finished.
Sometimes, The Requirements Ain't The Requirements
As Developers, we are unfortunately at the business end (pun intended) of all of this. We only get a neat list of to-dos and then we clock out and go play Apex Legends.
As a former Business Analyst, however, I feel like I need to let Developers in on a dirty secret: they really need to be at the business beginning of software updates.
Because, as my former Boss once told me:
Sometimes, the requirements aren't the requirements...
Sometimes, you'll be coding something that makes zero sense. Or might be totally unfulfilling or unworthy of your time.
And it's true.
That user story to "turn the button blue" probably came from the client who probably actually just wanted to update the button styling.
And then it telephone-d into this update where it's now a conditional rendering exercise versus maybe an exercise in updating the CSS.
Or sometimes, you'll deliver an update exactly as promised, and the client still won't be happy.
For instance, I had a client who wanted to make all their images have rounded corners. They were adamant about it.
Sounds easy enough, right?
Well, we did it, and, guess what, after we did, someone else at the client asked why we agreed to do it.
Because we basically spent valuable Developer hours doing this when there was a juicier project sitting there on the shelf.
Conclusion
Needless to say, you can see why I put my life as Business Analyst behind me.
But, while I love being a Developer, there are other things out there behind the scenes which can make our jobs good and bad.
While it should be our job as Developers to build the darn things, it's also our job, unfortunately, to question why we are even doing the darn thing in the first place.
Food for thought the next time you get a request for rounded corners on images.
Sources:
What is Agile?
Acceptance Criteria and User Stories
Top comments (0)