Yesterday I was talking with a client and was happily surprised when he sent a very detailed document on his requests. I mentioned to him that it was a lot more than what I usually get and he told me he used to work in an analyst role where he acted as a liaison between developers and stakeholders. The hardest thing he said was making sure developers got the feature right.
And he is right. Many times in the past a customer or even I have thought there was a bug in an app or website because it didn’t behave as I expected. Typically these are reported as a type of bug even though the app or website is technically working.
You might be wondering? What’s the big deal?
Well, one of the main drawbacks of developing software is costs. The surest way to go over budget is to have to re-do work!
Now it might seem simple to describe a feature, but it’s amazing how easy it is for language to be interpreted in a completely different way. Also, it’s very hard to think about everything regarding one small feature let along one with many moving parts.
So a few years ago as when we were expanding our team, I was looking to find a way to limit this extra work when passing work to the rest of the team. Not only does this reduce costs, but makes our team more efficient because they are not waiting on our client to answer questions.
The solution?
Agile Development
In particular, incorporating backlog refinement meetings, user stories, and acceptance criteria
What we found was that by having regular meetings with the stakeholders and developers, we were able to clear up any questions that might come BEFORE development even started. Not only we were on the same page but it even allowed us to improve the feature or catch something we didn’t think of before. All because another person was involved in the conversation.
The other nice benefit was that by having an acceptance criteria anybody, technical or not, could follow and determine whether that story was complete.
So what does this look like in practice?
Template
User Story
- As a (*who* wants to accomplish something)
- I want to (*what* they want to accomplish)
- So that (*why* they want to accomplish that thing)
Acceptance Criteria
- (Given) some context
- (When) some action is carried out
- (Then) a particular set of observable consequences should obtain
Example
Story
As a coach, I want to invite a single player to my team so that I can include them in upcoming matches.
Acceptance Criteria
- Given coach has created a team when viewing the team details page then display an invite player button
- When a coach clicks on the invite player button then display a modal containing:
- A text box
- An Invite button
- A cancel button
- Given a coach has entered a valid email when the coach clicks the invite button then send an invite email to the entered email, close the modal and show a success toast message.
- Given a coach hasn’t entered a valid email when coach clicks the invite button then show a validation message explaining a valid email needs to be entered
As you can see just from a small feature like this, there are a lot of areas where if not specified the person developing the app might have to fill in the gaps and make certain assumptions that might or might not be correct.
