The Better Business Analysis Institute presence, the Better Business Analysis podcast with Kingsman Walsh. Hi everybody, and welcome back to the Better Business Analysis podcast with Benjamin Walsh. And I apologize for my voice. I have been down with COVID for the last week, but we're going to continue on our BA Byte series. And today we are going to follow through 10 top tips for writing
awesome user stories. So if you follow me on LinkedIn or you are, you know, one of my, I guess, friends on there, you will see that the Better Business Analysis Institute published a white paper called User Stories 2.0. And we're going to get to that in #10 but we're going to count down 10 top tips. These are really important.
I dip into the subject a lot and I think any BA, doesn't matter if you're senior or junior or getting started, will get value from from today's session around writing effective user stories, which is critical. And you, it's critical because it ensures that the delivery team, the development team, are building staff, features, deliverables, approving processes that actually deliver real value. And real value is not just a buzzword, it actually means something the customer cares about.
So we're going to walk through 10 top tips for writing awesome user stories with examples focusing on clarity, actionable details and connecting user stories to the broader business process. We'll also introduce the User Stories 2.0 concept which the Institute has published, and I'd love to get your feedback on that. So let's dive in with number one. Number one is keep the story focused on user value or
customer value. Ensure that the story is centred on the user's needs and the value they will receive. They receive a value item. OK, User stories should not be about technical tasks. OK, there's a lot of people out there who write user stories to talk about what they're going to do. No, it's not about technical tasks, but about delivering things, features, if you like, that solve user problems or provide benefits.
I'll give you an example. As a customer, I want to see recommended products based on my previous purchases so that I can quickly find items that match my preferences. A lot of ecommerce sites to this, OK. And of course, there's acceptance criteria under that you can put in the description or the acceptance criteria field, which will be recommendations should be personalized based on my previous purchases within the last six months to introducing a bit of a business rule.
There some constraints around the user story. The recommended product should appear on the homepage when the user logs in. So this is description of the user story. This is the comic book. So when you write your user story, one of the best ways to make sure you've covered it off is draw a little comic book strip. OK, if you're from the world of user stories and not use cases and traditional business analysis, visualize how you think this will become true.
And some of those additional points will become description acceptance criteria in your user story. It's #1 keep the story focused on user value #2 is be specific with the desired outcome. Clearly define the outcome or benefit the users should be experiencing. Vague goals lead to misunderstanding about what should be built. OK, and this really focuses on the so that I aspect of the user story.
So here we go. As a project manager, I want to receive e-mail alerts when tasks are overdue so that I can follow up with team members to avoid project delays. Lots of people could have written so that I receive an alert or so I am notified. They just rewrite that I want to and the so that I This is an easy problem. Don't do it. It is my advice if you catch yourself doing it, and sometimes you do it because you're rapidly writing these things, go back and change them.
OK, So you need to think about why. Why is that feature? Why is that function important to the person? And it's usually not a technical reason. And so in this case, it was actually so they could follow up because it's really important. At least there's so many other aspects of product management and why you create value and by the alternatives. And when things are tough and you need to prioritize, then the why is all that matters. OK. And so again, you can have acceptance criteria.
Alerts must be sent when a task is more than 24 hours old. And the task alert should not include or should include, sorry, the task name, assignee, due date, and so forth. So that's really around #2 which is be specific with the desired outcome #3 is really important. And I'm going to talk about breaking down in more detail here. Breakdown user stories or stories, the general term, into small manageable chunks. That's the whole point of the
agile cycle and sprints. So large stories, epics are hard to implement in a single Sprint. That's the purpose of breaking them down. So there's two reasons. One is the side from the delivery side that they're too big, but they're also a great start, as I said, to, to link to traditional business analysis and real business analysis, if you like, of capturing high level requirements first.
But you do need to break them down into smaller, more manageable user stories that can be completed within a Sprint. And so you could break these down again into child user stories. So you might and and and a child user story might supersede the the previous user stories. So you can either have children or you can archive and just have smaller more user stories if you like. So I'll give you an example for a large area, like, I don't know, managing my orders, you could break that down into
smaller stories. As a customer, I want to view my order history. So it's a it's a sub function of or managing my order. OK, so that I can track past purchases or you might have as a customer, I want to update my shipping address before order is shipped out. So these are all sub features. And again, you can visualize this if you draw up what you think is a conceptual version of an order strip screen, this really helps. This is not cheating. Some people think you're
bringing up pen and paper. It's like, oh, you're starting to develop, you're starting to design well, you'll know you're just conceptually thinking about it. There's there's, you should be doing this as a VA draw a picture and go, oh, what's on an order screen or, or look at your order screen. So you're like, well, they want to be able to be able to view their order history, don't they? And update their shipping address.
And so this is all part of it. This is all passive, the analysis and design in the sense of business analysis. So you do that and you go, OK, well, we've got this, this massive epic around managing my order. We're going to manage my order screen, but actually now we've got some sub components if you like. They will be components by the developer's side. And from your point of view, they're just, they're functions that need to be reformed. OK, the user stories and you can
write them down even further. So for example, you've got to a point where you're like view my order history and the order history screen was massive. That's where you could say, look, I really want them to not just view the order history, I want them to be able to view specific details of their previous orders, right? So like go back in time, see what was delivered, when it was delivered and all the rest of it. So that could be another user
story. So you, you get into the order history and the, it's come from the product owner. They've spoken to customers and they want to track past purchases and you find out it's a bit more than you thought it was going to be. It wasn't just the name of the order and the item. It was like when it was delivered and submitted data around the order. So that's a child user story of that particular user story.
Or you could just create a new one, add this backlog and say, look, we're going to implement this version of it. My order history as this user story 1st and then it's going to be my order history details, view or advance details or track that on the backlog. And that's not going to be done this spring. That's what we mean by breaking this down. They all contribute to the epic which was managed my order. Does that make sense?
But there's a relationship between view my order history and this new view my order history, you know, details and that there could be linked as a child user story or just Simply put on the backlog at the kind of same level. I like to use child user stories and that's why I would break it down, OK, But it wouldn't be implemented in that Sprint. It doesn't mean that the children are all done in the same Sprint. OK, let's move on to #4 add
clear exceptions criteria. So just to be clear about acceptance criteria. Acceptance criteria define how the story will be validated. OK. And this helps the developers, the testers and stakeholders know when the user story is done. So they the the definition of done. How do they not? And how do they know it's working as expected? So the acceptance criteria is being is not a, well, by the way, defined area.
And it's something that I'm quite interested in having wrapping some guidance around, but it's being increasingly used to fill the gap of, say, documents that have business rules in them. So I'll give you an example. So as a user, I want to reset my password via e-mail. OK, It's quite interesting. It's got via e-mail. She's now specifying with what channel, with what. OK, so we'll come back to that so that I can regain access to my account if I forget my password.
Very standard user story. It's one of these user stories that you sometimes forget to Chuck into your app because you just assume the developer's gonna, like, do all this. And I've done that before. And the acceptance criteria under this user story is that the user story can request, sorry, the user can request a password reset by entering your e-mail. OK, that's different. It's more descriptive. It's saying that they have to
enter the e-mail. So that that if you like, you could break this user story down into further user stories around having a field or an area where a user can type their e-mail address, a valid e-mail address. Can you see, can you, can you see how you could break this down into other user stories? But in this case, the acceptance criteria is enough for the developer to visualize what they are going to build and they've
recognized as patterns. So you I would say there would be less value in writing another user story or child user stories here. But the first acceptance criteria is around by resetting by entering their e-mail. And the second one is a reset link is synced within 5 minutes of the request. OK, you set your e-mail address, you click reset password and then within 5 minutes the request should be sent back. And there's some importance about that. I mean, you could say instantly.
And then that can involve huge amounts of tests. I happen to know because I've got a bit of a development background, that it will be queued this request. And it might not be possible if everyone's resetting their password. It's not really a priority job. So 5 minutes is pretty standard, or I don't actually say a couple of minutes these days. People would expect an e-mail reset or they'll go back and reset it again. And then the last acceptance criteria #3 is the reset link
will expire after 24 hours. So it's around security and making sure that it's not forever or hackers can't gain access to it. So that all what I'd call business rules that you're applying in the acceptance criteria and that all have to be true. So that allows the user story. Ultimately the resetting happens and you've specified some rules around how it has to happen. 95 is so important. User stories.
You get so wrapped up in your epochs, user stories, product features, all the rest of it. Don't forget about non functional requirements. Most projects that encounter big disasters when they go live is because the BA and the team and the architect haven't thought about non functional requirements or done a good enough job. They are overlooked. They are critical. They are critical not just for your reputation, but for user
satisfaction. So we just talked about before around there was this resetting option, What would happen if we hadn't specified a time or worried about performance of this particular resetting of password or even security? OK, so we for example, when we reset the password, we sent the old password in the URL. That would be a security problem, a non functional requirement. We should have to to make sure that doesn't happen. And that would cause a security risk.
And actually people would be able to just instead of resetting the like they can just take the old password, enter and get into your account. So you need to think about things from a non functional site and there's usually templates. I've got lots of good content about non functional so I'm not going to go on about the point, but I'll give you an example here.
As a user, I want the system to respond quickly when searching for products so that I can find items without delays and this will stop me from going to other websites. And so the exceptions criteria could be search results must repeat appear within 2 seconds of 90% of queries. The system should handle up to 10,000 concurrent search
requests. So these are all non functionals around the interaction with the system in order for the features functions to operate correctly, securely, you know, performance, a scalable, a usable and and this includes things like content and web standards as well. So they're all come under non functional requirements. So do not forget about non functional requirements. Number six is and I actually had this conversation with someone a couple of weeks ago. Focus on one persona per story.
Don't have a group of personas. Think about the individual persona, individual user that you're focusing on. User story should cater to a specific type of user or persona. Trying to address multiple personas and a story creates confusion and so that I it's really talking about the individual persona. So as a System Administrator, I want to manage commissions and the control panel so that I can control access to different
parts of the system. And then an, except described here, you might say something around admins can view a list of items, they can grant or revoke access to specific modules. Now that's around the system user System Administrator. And that's a good example because it's around the people that you sometimes forget about, especially when you're building a system that you think, oh, we haven't built an area where the System Administrator can actually control permissions.
We've just got a user who has a credential, OK, and just gets allocated or wrong, but someone has to manage that. So that's thinking about the individuals in the life cycle, your stakeholders that are managing the system as well as interacting with it. OK. They all are important and we need to think about them as individual personas. So yes, and as, as a it should be, it should be unique there. And sometimes just as a top tip, sometimes that can be a bit of a reply.
So early day business analysis and system design, you would do like a sequence diagram, for example, sometimes or you would do a use case diagram. And so think about a baton approach. And what I mean by that is, look, as a user, I want to be able to view a list of products on the site so I can browse and decide which product I want to purchase. And then so I've I'm doing that now, what is the response? Who needs to? Does anyone need to do that? Does the system need to do
something at that point? As a system, I want to respond to searches for products within a timely meeting. So the better meaning that I've done my thing, now I want the system to do something. And if you think about it that way, again, like a comic book, but with all the characters, including the system as a character, you won't miss all the user stories #7 make the user story testable.
And so we do that by doing great acceptance criteria, but we also need to write a user story in a way that testers can validate whether or not it works as expected. So an example might be as a subscriber, I want to be able to cancel my subscription from again, where? From the account setting page so that I can stop being billed if
I no longer need the service. And then in the acceptance criteria you might have, the user can navigate to the account settings and see a Cancel subscription button. Clicking the button triggers a confirmation response calculation is processed and the user is notified by e-mail. That completes the whole actual comic book, the story side of the user story. They need to be testable, so make sure that you're writing something that can actually be tested. If it's not, then you may need
to reword your user story. And they're not all. For example, numbers or counts could just be binary. Does it work? Does it #8 is prioritize just user stories by business value, not by development preference? Not by what you think is the most important, but what the user, the customer, the business thinks is the most important. This ensures that the team is always working on the highest
impact items and features. So for example, as a customer, I want to be able to track my order in real time so that I know exactly when it will be delivered. Now that's an example there where a user wants to know when they want to track my order. Now let's say there's another user story which is as a user, I want to be able to view where my order is at, OK, so that I know when it will be delivered or I get some idea about when it's going to be delivered.
So the fact that we have two user stories, one which is just a roundabout to track my order bit more light and the other ones around tracking in real time, which might be a should have requirement. The business value might be just to implement the tracking order first and then you will do the real time tracking and a next Sprint if it's deemed highest value. So you need to prioritize these
things. I would suggest that a trick to fight to even realizing whether or not a user story is the most valuable is that it allows the user to complete their journey, their job to be done, so they're able to complete their full cycle. So you should focus on them being able to perform a step. OK, just yes or no?
Can they complete that step tracking their order or viewing the order or checking out before you start to work on user stories which aren't MVP for And what that means is before you start adding additional features to other areas #9 is is never done well here. And that is considered dependencies between stories. Sometimes 1 user story cannot be fully implemented without completing another. OK, like I said, there might be a user journey.
So that's literally the the journey of the customer to get from A to B. That's important. Your storyboard should show that. But also in delivery there might be some dependencies that ensure smooth delivery. So for example, they say as a customer, I want to pay using PayPal so that I can complete my purchase using my preferred payment method. That's a pretty common user story here. And there will be some acceptance criteria that go
under that. But what we might realize is that that's someone's working on that. They're building a screen, they've got the PayPal logo, they've like designed it really nicely. They've given the user option, but there was no point in doing that user story because I haven't completed as a system. I want to be able to integrate with PayPal to provide PayPal payments. So the Paymal integration must be completed before implementing this story.
So you don't just focus, you do focus on the user value from the storyboard point of view and what's the sequence. But ultimately, you also need the development team to think about what user stories need to be done and what sequence. So for example, you can't offer pay, pay by power Pal to a customer, which is high value if you haven't done PayPal
integration. So if there are sequences that you just need to focus on, and so that's using dependencies prerequisites, that would be fantastic. And you can do that in tools like Jira, Jira and DevOps. And #10 #10 is to adopt User Stories 2.0 to include triggers and HDS. So to address gaps in traditional user stories, you can adopt User Stories 2.0, which adds 2 critical components with User stories 2.0.
What we have introduced here at the Better Business Analysis Institute is both with trigger, OK, So that allows us to know what entity are we affecting. This could ultimately end up being a feature in your development. So it's an output, a page and area. So that is, but entity is a really good way of looking at it. So it's like with car or wheel, OK, a conceptual entity that you may have drawn up and we introduce a win, a trigger, a condition.
So that allows us to talk about timing and what needs to be true. Now this won't necessarily replace all the business rules that you have in your acceptance criteria, but it will give you the main reason for why and when. And with this user story functions around. So this is the format that we use as a persona. I want to right perform function desired feature whatever it is so that user value goal when trigger condition with entity being affected.
So let's work through a really good example here. As a customer, I want to manage my e-mail subscriptions so that I can choose which e-mail I receive when my account is activated OK and managed with the account setting page. So you've, if you're ABA working on detailed user stories, you should be in the development team. They're talking about how they're going to design it. And you already know conceptually there might be an
e-mail settings page. You should have drawn that up probably conceptually and you're thinking about it. You say, well, I want them to manage the subscriptions in this area. So why don't you be more explicit when you're in the detailed planning phase, you're in the Sprint and you talk about, well, where, where do you want this to happen? So that means the developer now knows, and you may have drawn a picture of this, that that's where this function should take place.
So they're not building a whole other area or they're not guessing. So you're being really explicit. You're, you've visualized that this would be a setting in the account setting area, OK, around managing your e-mail subscriptions. So that makes things really explicit. So with user storage 2.0, you're adding the when and you're adding the with. And in this case, when was just the fact that you had an account
OK? It wouldn't be for customers who weren't logged in or for customers who hadn't signed up yet. So it was when they had an active account. So that again, talks about security gives quite a lot around the both the state of the
account. And of course, it might just be any time they want to do it. And whenever I choose to update my subscriptions and the worth of game talks links it back to the architecture, to the actual reality of the fact there's a component which needs to be built, which is your account settings area. So have a read of the white
paper around User Stories 2.0. It isn't perfect, but what it allows us to do is bring in some of the things we lost from use cases which aren't used that often and business rules and process and starts to really allow you to incorporate all the thinking that you have done as a BA into the user story.
So it doesn't just get lost. So the other thing, of course, is adding visuals to this and pointing to this is really helps linking back to mock ups and a process diagram around when, when do you allow them to do this? So this feature, for example, which is around being update your subscription preferences, your emails subscription can happen kind of whenever throughout your kind of managing account, your account life cycle and other examples.
There will be specific time periods when things happen like, you know, the 30th of every month, send an e-mail to someone. OK, so you can see the timing and this so that will link to your process diagram and to your mock ups. And it means that your user stories are full and complete. So there are 10 top tips to make your user stories awesome. I hope you got value. Apologize for my voice today and I'll see you next week.