Okay, so welcome back everybody we're gonna talk about capturing agile requirements stuff. And we'll talk about things like epics and user story, acceptance criteria and the acronym BDD which you may or may not have heard of. Have anyone had to BDD before? Nope, yeah. I have, yeah. What have you heard about it? I tried to bring it in when I first joined the University of Business Development, Business Driven Development. Excellent, excellent. Well, I'll try and help you with that, right. (Instructor and Student laugh).

Right okay, so a user story I've sort of given the game away almost seven times with the user stories but, if we were gonna, if we were gonna define a user story what would be a good way to describe a user story? A user story. Is it, a functionality that a user would try to like achieve through the use of an application, So as a user wanna log in and yeah. The (indistinct) (indistinct) and encapsulated (indistinct) and so. Yeah. Yeah, yeah, so that's that's right. So it's certainly it's written on behalf of the user.

So definitely, so identifying it's something that a user would do. It's certainly written on behalf of the user and you're identifying a terminology that helps us focus on that fact. So we often describe, we often describe a user story using a specific kind of phraseology and we'll say as a, and then we'll identify who the actor actually is. And so it's, some capability it's some functionality. It's some requirements that is written in terms of the user for the benefit of the user. And we so we identify all of those things.

Who's the actor? What did they trying to achieve? And what's the benefit of that? What was the benefit of them achieving what they're trying to achieve? And we've kind of answered that question already. What should a good user story contain but as well as describing what the user story is about what else do you think a user story should have associated with it? So we've said it needs to describe the actor, what we're trying to do and why we're trying to do it.

What else does it need to be a good, clear story? Value. Value, yeah, there needs to be valued, shouldn't? there needs to be some value to the business. It needs to align to a business goal. But what else? If we're gonna write functionality around it as developers, what do we need to know? The definition of when it's done. Definition of when it's done? Yeah, okay so what, does done mean on it? And in order to know that, we need some more detail maybe? Is it possibly how it's done or is that's through prescriptive? Well maybe how it's done, but, what's important, what's important about this is, are there any rules, are there any-- Constraints Constraints, yeah so there are, so in other words what are the acceptance criteria that might mean that this user story works or it doesn't?

So what are the acceptance criteria around this user story? And what are the, what are the acceptable what's the acceptable path? What is the unacceptable path? And so the acceptance criteria that is important are there any functional criteria? Are there any nonfunctional criteria around it as well? So there's lots of extra detail that might be necessary.

The product owner is clearly responsible for talking about user stories, and a few of you have already mentioned that, and then we just talked about why do we need acceptance criteria but, a different question then is what would you do with acceptance criteria? You could use it within reviews at the end of sprints to ensure that you put quality assurance. Yeah, okay so, within reviews and quality assurance but, if the acceptance criteria are describing what is, what makes us user story acceptable and what are the rules around the user story? What might you do with those rules? The correct unit tests.

You could correct tasks, couldn't you? Absolutely, so if the requirement was for a banking system for a cash point system, and it was saying we're going to allow them to withdraw cash from their bank account. And we might say, well, we're only going to allow them to do that if there's enough cash in the account. So, I mean, it seems silly to have to say that but, we do need to say it. We need to say that, only let them withdraw cash, if there's sufficient balance. And, what are the rules around that? What should happen if there is insufficient balance? What should happen.. What's the limit? How much of that, can they just, can they withdraw their entire balance? Are they only allowed to withdraw 50? Are they allowed to withdraw a 100? What are the rules? What's are, what's acceptable? And so this is what you might start bringing out your tasks.

Business goals. Whenever we have a project the project itself, ideally will have an overall goal. What's the purpose? And then the project goal would ideally again, be broken down. So it looks like there's, some of those arrows like misaligned but some of those project goals would be themselves broken down into a set of business goals. So one of the business goals might be to improve payment processing or to improve the order processing or to add additional forms of order processing or whatever that might be.

Streamline the procurement process might be a business goal. Some of the outcomes from that might be, might also be important what, from the business goal, what are those outcomes? So those, outcomes could include, to add might be adding additional payment processing channels and many other kind of many other outcomes may come out of as business goals.

Now, the outcomes themselves very often turn out to be epics. So they're reasonably big pieces of work but what we always want to do, whenever we are identify and, whenever we're identifying this kind of hierarchy, we always want to make sure that the user stories that we're writing, aligned back to an outcome and a business goal. And they're always, the whole thing aligns back to the original project goal.

So, it's always a good idea, whenever a project is started to have a good understanding at these top levels, because without this the lower levels, can often become kind of blurred. And we can end up working on pieces of functionality that have no relevance to the overall business goals and the original project goal. And so understanding what all of these actually are, is quite important. And I've worked with quite a few organizations where they understand this is a hierarchy.

Sometimes they don't have as many levels. Sometimes I have more levels, but understanding this hierarchy and understanding that their, the requirements that they come out with align very closely to their objectives, is really important. So discovering requirements from the user perspective, user stories. So questions to ask would be things like who are the users, do some users perform similar roles and if they do, we would aggregate them into generic roles or personas? And what do those generic roles do or maybe what their attributes are?

Determining the business outcomes defining the benefits. What are the required business outcomes, understanding what they are? What does the roles need to achieve to do, to achieve these benefits? And do these outcomes align with the overall goals of the business? And like it says here the outcomes typically map to epics, one or more epics. And so understanding that hierarchy then starts becoming much more important.

So when we go back, you can see that, taking a step back in your project and say well, actually do we understand what it is that we're trying to achieve? What are the goals, and what are the desired outcomes?