The Better Business Analysis Institute presence, the Better Business Analysis Podcast with Benjamin Walsh. Hi everybody, and welcome back to the Better Business Analysis podcast with Benjamin Walsh. And this week we continue on our BA Byte series. That's right, we're going to be talking about why you would breakdown requirements, why would you breakdown news stories? What's the point? When do we do it?
Why would we do it? And this applies no matter what kind of project that you are running. If you're running a pure agile shop, this applies to you. If you're running a waterfall rigid approach and maybe an organization that has a very clear business case framework, or if you are somewhere in between the fragile framework, somewhere in between, then this applies to you. So this is, it doesn't really matter what methodology you're using. And our job as ABA is to make
things clear. It is to make things concise. It is to bridge communication across stakeholders and it is part of the job. If you're wearing, and this can't, just to be very clear, this can sometimes fall to a product owner in a pure Scrum environment where they don't really have ABA. So this applies to you, your job is to make sure that these user stories, these user stories are are fluid, that they evolve that that's OK and that you do that
though in a series of stages. You do this in pre project stage. If you're involved in that or our BA does that for you, that is ABA role. You do this at the front of a project. And I would say that that's also ABA role, the high level requirements phase before you get into development, whatever you call that phase. And then there is the development phase where either ABA or a very good, well trained product owner who has BA skills is doing this for you.
So let's get into it when you are in the pre delivery phase, so you're not near development, right? And, and, and I talk about this often, there is a phase, there's a pre project phase and even in the start of the project, once the project's kicked off, there's a high level requirements phase, whatever you want to call it. There's a phase that happens before you get everyone involved in the nitty gritty and then you have the development phase.
OK, so that whatever method you're using, we have methods here at the Better Business Analysis Institute, but whatever method you're conforming to, I'm going to assume nothing here. There are three different phases. There is the phase before the project's kicked off feasibility. There is a phase at the start of the project when you're doing high level work and then there is a phase when you're doing detail work. And that happens in the delivery phase and the development phase.
And so you'll use the stories need to cater for those needs before you get into the project. Your epic stories should be done and ideally you might have, you might have, and this is a might now a very, very high level user stories depending on the
complexity of your program. If the epics are just too big, when I say too big, too big for someone in the management team or the business ownership team to really understand what you're talking about, you may break it down further with examples, which might be the start of your high level user stories. Depends on the size of the price now in pre development. So the phase, the high level requirements phase, I like to call it, you are still understanding user needs.
You're contacting, you're doing workshopping, you're doing interviews, you're doing surveys. Things are very, very, very fluid at this stage, right? And you're now talking about what we need to achieve when it comes to those epics, which are a kind of, if you like our goals and we need to make sure our user stories accurately reflect the needs and expectations of the end users and and stakeholders ultimately, right. And so you are creating high
level user stories at the stage. And I like to do that in Excel before I put it into the Azure DevOps, for example. That's just a tradition because it really says, hey, developers, I don't want to you to look at it. But as those tools, Jira and DevOps become more of the BA tool of choice, that you may well find that it it makes sense to start in that tool and just kind of flag them as such that they're not, they're just in the backlog. Nothing to do with sprints at this point.
Now, when you are are describing your high level user stories, you want to be clear and concise, as I say often about what the solution should be achieving from a user's perspective. You are prioritizing those in terms of masks, should, could and would. Usually when you're in the development phase, people just assume that everything in the backlog needs to be done at some
point. And obviously in the Sprint planning, you do what needs to be done now from a from a task point of view in order to achieve the acceptance criteria or the Sprint goal. But I think your Moscow rating should have been applied with the product owner before you even got into that phase. OK, so you, your job as ABA is to focus on delivering the most critical parts of the job to be
done. Sometimes people talk about features interchangeably and features is still a mystery in terms of what that actually means. And we, you know, and you can I avoid the word because it talks about system functionality and so I avoid it.
But what I'm trying to say is the most critical jobs to be done, things that need to be done like from a from a customer's perspective or solid conceptual parts of the solution, which could be cool features is your job is to make sure that they are you are focusing on the ones that maximize the value early on. OK, now you go, OK, well, I can do that in Excel and I've got that in there.
I've got it in DevOps and I've sequenced them and I've talked to my product owner or my business owner or I've put in, put in my Moscow's, right? I'm done. No, there's another lens you need to apply. You need to do some story mapping, OK, And the story mapping brings us all the way back to human centered design and what you need to embrace as ABA. You need to sequence these on a visual board, a whiteboarding
tool. OK, ideally a physical board maybe behind where your project team sits is fantastic and you need to throw those user stories up and go if we if I was a customer or a user who needed to complete this job. So from end to end, all the epic steps, OK, in order to achieve
my goal, have other in gaps. Your job as the BA is to apply logic and go actually we've totally missed a whole user story or set of user stories around maybe if you're creating a new report, we've totally not talked about the channel. We've not talked about how we're going to get the actual report
back to the user. There's a gap in your user story because and then your user journey to be honest, both because you haven't talked about that and if and then those if you have a gap, assumptions will be made and and the development team will make those for you. OK, Or otherwise it may be too late to think about that when you're mid development, when you've actually not conceptualized or even had a discussion about how much work would be involved in that.
I'm not talking about some Agilos might jump up and down here and go. That's our job. It's not not talking about your team. I'm actually talking about maybe there needs to be some user workshops about how we do this feature. They could, they could literally take the same length as a few sprints. OK, it could take months.
So you need to do that as ABA and be pretty damn happy that you have identified all the gaps or if there are gaps that the product owner understands why the gaps and they're just not important or you're not making a change, right. So if you just use, if the user story is to just use all the channels you use today, great. OK, put, but explicitly put that
in the as a user story. Even though you're not changing it, it's really, really good to just mark them straight away as out of scope or already done or done straight away. OK, you haven't even talked to the development team, but you know that that's already done. Or you would take them to the first Sprint planning and go, we know that these are the user stories and they'll go, well, that we already have a, a way to solve that and solve that and solve that.
It's to reuse what we've got and you'll go, great, cool, done. But then you've actually got a trial. And then you can see where the gaps are in that visual user story and which ones have been fulfilled by reusing functions or features that you already have around the organization or current state. If you like, you're not changing
the current state. Finally, in the development phrase, this is where you take whatever user stories, high level user stories you have and generally probably be one level. They may have child user stories at this point, depending on complexity and you'll decompose them in the proper Scrum way of decomposing an agile way where you are decomposing the user stories from the perspective of the doers and the doers, the development team, the delivery team are going, oh man, that's
that. Use a story there. That's quite a chunky one. I want to break that down. I need that to be clearer. And so you and that's OK. It's you haven't just gone. Sorry guys, this can't change. You've got it in the words of the of the product owner at this stage, they understand. So your job is to then help work out how you'd break that down. And there are some good tricks for this. Again, I could speak about this for hours, but I won't. This is a bite.
If you have a user story, right? And it's, I'll make one up as a reporting user, OK, that's not really descriptive, but I'm just going to use that as this case. We're going to be an internal user. As a reporting user, I would like to view and receive a copy of the new payroll performance report every Sunday so that I can continue my steps on a Monday to review that and do my job right. That very loose, not well thought of off the spot, but that's great. It's a high level one.
Check that into DevOps and work with it. You're not the you don't have to be the best writer in the world. You just work with the product owner and make sure it and you've articulated what they want. And that's why you have another side top tip. That's why you'll use the story name, your description, the what you've just talked about is different to the description. Some people argue that the description is acceptance
criteria. I think it's actually just really defining what you mean by that statement and acceptance criteria separate or underneath the description. So you've got that right. And you say, well that's great user story, totally understand what that means at a high level.
You go into the development phase and the development team goes, OK, so you want us to be able to allow them to have access and you're like, yes, OK, you want them to be notified and you're like, Yep. And maybe you want them to subscribe to the report because our features or their they are features that we can provide with maybe our architectural reporting tool that we've already got. And there is no requirements to suggest we're going out to
market or changing that. And you're like, yeah, completely agree. When we write that, we just assume that we're going to use Power BI because we've got that and they're like, OK, Yep, confirmed. We will, unless there's a requirement, suggest otherwise. So could you break that user story down just to be really clear? And to three, what we would like to know is who needs access where they would review, view that report, right? And the other one could be user
story around scheduling. So that one user story that you had to start off with, you've broken down into three. And one way to do it just to get rid of the original user story and have three new user stories, right? Or create a child user stories. So you have evolved that one user story into three, right? And the one parent user story encapsulates those three functions.
Now that the only reason you would break down into child user stories and not just, you know, basically superseded Evolver from 1:00 to 3:00 is if you had intense traceability backup, right? So I do like, and it's only recent time where I've started to use the concept of child user stories and then mark that top one as being apparent. And you could say, well, that's an epic because you're breaking it down. It isn't an epic because you
can. An epic is an ultimate goal that should encompass a whole lot of views and it comes from the view of the product owner of the business, not from the development team. What's easier for them to do tasks equally as I've seen also done before, as the user story remains and it has three acceptance criteria, which are the three functional areas you're talking about. And it really depends on the preference and pattern you use
in the development phase. OK, when you define your acceptance criteria, there are conditions in which the user story is considered complete. You they those acceptance criteria. Just be really clear here. If you're using the acceptance criteria to define those different functions, completely separate functions that add up to one experience, that testers will use those acceptance criteria. So you need to predefine which way you're doing this, not midway through.
OK, so if the user is going to create test cases, if you're breaking down into child user stories for each function, the test cases will come straight off the child because it will be 1 acceptance criteria per child. If you're doing more of a bundle because it makes more sense though, and the development team are not dummies, they should understand the the user journey here for both viewing, receiving and scheduling a report.
They you could have the three acceptance criteria and the one user story, but then you would you would have at least three test cases under that. And again, test cases have hierarchies. There could be a test case at a high level, and then they can be broken down into smaller tests or smaller actions. Do you need consistency there? And of course, you continuously refine this.
Every review, every backlog refinement, every time you go into the Sprint plan, they can adapt and you need to adapt the user stories. And that's why I like that. Keeping that traceability, definitely the ID number should be traceable all the way up to the epoch being the front of the user story, you know, So if you've got an epic one, your user story should be 1.1. OK, That's how I control that.
It helps really. User stories help us as a communication tool to talk about changes and, and how they've evolved. And a project manager might freak out and go, we started with 10 user stories and now we've got fifty. Well, that's just normal.
And so after that initial review, the initial planning stage, and I know you're supposed to go straight to sprints, but as you're doing backlog refinement, you should have a pretty good idea after the maybe Sprint one or two, how many kind of user stories you're going to have, OK, it will start giving you an idea if you start breaking them down. That's all part of agile. That's the whole point.
So you can't just go the project manager's freaking out that you started with 100 and now you've got 200. Well, that's just the nature of deciding to run your project in an agile way. OK, You can use that to track progress, obviously, and see how things are going. And yeah, don't I guess I just want to leave you with the thought that it, it feels sometimes wrong breaking down
your user stories. It kind of feels like, oh man, I've just perfected these user stories, I've captured them and now you're breaking them up. As long as you have the traceability, that is their purpose, OK? They're not supposed to be the beyond end all. What doesn't change are your epics. OK? And if they do change, sorry, epics can change, but that would be with a major change to your
to your project scope. And if you're using the breaking down as the children user stories approach, which is my preference, then you could save those high level user stories change. You need to do a change for a request for change. OK guys, I will see you next week. I hope you learned something this week.