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.