“You have to be kidding me! Don’t tell me I don’t know how to write a story!” I overhear a BA in my scrum team as he receives critical feedback about his story.
Wait. Back up a bit. What is a story?
Friends, this morning from a corner seat of my corporate life in the heart of Sydney CBD — we will be talking about stories, the good, bad, and the bastardisation of it.
Long before Agile existed, in the world of software — people and businesses specified what they wanted in the form of requirements. Most of these requirements would live in a requirements document, and the process of acquiring, verifying, and validating these requirements took a very long time. It was a different world back then.
Fast forward to now with changing market demands, it is now critical to be able to adapt to when the market calls for it. Agile came, and it brought techniques such as scrum to build effective teams while delivering product increments often and (hopefully) quicker.
The story about ‘Story’ is that it is a requirement. Like everything else in Agile, the good people who started this following made sure that there is a formula to it. It’s simple enough:
As a <user> I want <functionality> so that <benefit/driver>
As you can see, there is a directed focus towards the user’s perspective. Fair enough. This allows everyone (tech or non-tech people) to grasp the work required to build our project.
So if Stories are relatively easy to create then why is this guy at work chucking a massive tantrum when someone told him he’s doing it wrong?
What are you doing wrong in your stories?
You’re writing a circular story
You may have seen these in your Jira tickets. A story that does not have a clear benefit or driver. The story is written something like this:
As a customer, I want to be able to customise my pizza order so that <I can customise my pizza>.
Mmm pizza..
Think about this. Do you want to customise your pizza order because you need to customise? Because you said so? Because the product owner said so, right?
The benefit is not clear. Most people who write stories tend to write the benefits part of the story as an afterthought. It’s a shame really, as it could make or break your story.
As a customer, I want to be able to customise my pizza order so that I can add non-traditional topping combinations to my pizza.
Now the insight to this story is that, the customer now has the power to select toppings that are usually not together, or that they have the power to put variety into their pizza. Boom!
You can’t figure out who to write the story for
So you write important but irrelevant stories such as:
As a solution architect, I need to write the design so that the team can start the work.
If you see or attempt a story like this, save your effort and just write it in your project’s to do list or list it as a task in Jira. This is not a story, bro!
You don’t update the story
Worried whether you’re supposed to update the story or someone else should?What’s the rule?
There are no rules! Let your team know that the story needs an update, don’t wait for someone else to do it, your stories will only get better if you take the initiative to do it. Taking care of the stories is not only the product owner’s and the BA’s job. It’s also yours. If they are a bit touchy about updating the story, add it in the comments section.
Word of warning about updating comments in your Jira tickets. Try and avoid misinterpretation through confusing and long messages. Ever seen a Jira story with non-stop list of comments and you’re supposed to go through the comments to understand the juice of it? Come on! That’s just bad form. Try this — when your group reaches an agreement or resolution then update the main body of the story and attach any necessary diagrams to back it up.
No one understands your stories
Here’s a sniff test. If people are asking questions repeatedly about your story, if they are misinterpreting it, if they are not actioning your story, if they are avoiding doing it — signs are that your story stinks!
I’ve had countless conversations with frustrated BAs, Product owners, and Scrum masters. They complain that it’s their team that don’t get their stories, or that the team is slow, or new, or just plain hopeless.
Really?
Back up a little bit, if I explain a concept to you and you don’t get it — then that’s on me. If I try again and you still don’t get it — it’s still on me. If we try again and still, you don’t get it — it’s still on me.
To be clear about it, there are no limits on the number of times I can explain to you a concept if you still don’t get it — it’s still on me! As one of the sayings goes “There are no bad students, only bad teachers.”
Mr. Miyagi is an example of a good teacher not only to Daniel san
So how do you stop your story from stinking?
Use diagrams
A picture indeed paints a thousand words!
Now there are many types of diagrams depending on your needs; they are not all equal (that’s right! merely putting boxes together and linking them up will not solve your problems) depending on the problem you are trying to solve — there are technical diagrams, process diagrams, logical diagrams.
I suggest doing a little homework on these as it can make a world of difference!
Again, the emphasis here is to help with communication. If your story is crying out for better explanation then consider showing the logic with a diagram.
Some of my faves are:
- Context diagrams for high-level context and understanding how areas interact;
- Activity diagram, process diagram for capturing process work;
- State diagram, Sequence diagram — for capturing moving parts, messaging, and states.
- Technical ones such as Solution design, class diagrams.
Use examples
Use a set of real-life examples to capture the tricky scenarios and expected outcome.
Use logic or rule tables
Avoid wordy rules (if you can) that are open to misinterpretation, use a rule/ logic table.
For example: Logic table of additional cost on your pizza, depending on the combination.
Use Acceptance Criteria wisely
Acceptance criteria have a formula of:
“Given that <action/trigger> then <expected action/ or result”
Look, no one is going to have a heart attack if you don’t follow the formula. The point of acceptance criteria is to capture the logic and interaction between the Business — Customer — and Technology.
Acceptance criteria will quickly tell you if this story has been thought of enough by the people building and testing it.
So what is that interaction between Business — Customer — Tech?
The Lens Business — Customer — Technology
Next time you create or look at a story, I want you to keep in mind these three lenses: Business — Customer — and Technology.
The mythical place in the middle is where the magic happens. You want to operate on this ground; you want your story in this section. This place is where your story takes in to account the business so that you know its critical value, where you have the customer’s experience in mind as you create the solution, and where you understand the technical landscape that will allow you to execute the solution.
The intersection between tech — business — and customer. In my mind, it looks like!
The mistakes of many Scrum teams is that they overemphasise on one lens neglecting the other two. Hence they the team suffer in many ways as they build the story: * They encounter a particular logic in the code that they have not anticipated. * They create something that is awkward to use from the customer’s perspective. * They over-engineer a particular functionality that delivers a small value. * They struggle to scale because they become reliant on the knowledge of people in the scrum team.
So how do you avoid all these heartaches?
Here are some sample guiding questions to help you shepherd the three lenses. As you read them through, you might come up with much more; the point is that now you are staring down at that story from these lenses:
Business
Focuses on addressing priority and scope.* What difference would this feature introduce to the product and company? Would it compete with others? Is it with functional performance? Aesthetics? Overall experience?* What are the underlying drivers or problems this feature is trying to solve for the group?* What is happening in the market right now? * What other ways can we help to address the problem? * How much importance and value will this bring the business?
Customer
Addressing customer experience, interaction, triggers, logic. Put your self in the customer’s or user’s place and ask these questions:
* What would they have to have done before triggering this scenario? (Pre-requisites) (Inputs)* What would I expect to see on my screen if I was the customer? (Outputs)* What actions would I need to do as a customer? (Interactions)* Should those actions be quite apparent for me to execute?* What customer problems or pains am I going to resolve with this story? * What does the happy path look like for the customer?* What are the unlikely scenarios that the customer can do? cancel, opt-out, etc…* Would a prototype help? Would an example and diagram help?
Technology
Addressing technology solution triggered by the customer* What are the formats of the reports/message needed? * Are there any existing rules and logic I should uphold? * Which system triggers when the user does this? * What interactions need to happen once the user triggers what?* Are there any performance expectations?* What does the happy path look from the system’s perspective? * What is expected of the system when exceptions are triggered? * Where is the solution architecture?* Would a technical diagram help? Who will be reading the solution?
By all means, this is not an exhaustive list. Only use this as a guideline. It’s designed to trigger that mind of yours to consider the three lenses.
How do you know a story is ready? That probably warrants another article, but for now, I’ll end this entry with “Oh you will know!”