1
00:00:00,400 --> 00:00:04,400
The Better Business Analysis 
Institute presence, the Better 

2
00:00:04,400 --> 00:00:07,760
Business Analysis Podcast with 
Benjamin Walsh. 

3
00:00:12,960 --> 00:00:16,160
Hi everybody, and welcome back 
to the Better Business Analysis 

4
00:00:16,160 --> 00:00:20,760
podcast with Benjamin Walsh. 
And this week we continue on our

5
00:00:20,760 --> 00:00:24,040
BA Byte series. 
That's right, we're going to be 

6
00:00:24,040 --> 00:00:27,320
talking about why you would 
breakdown requirements, why 

7
00:00:27,320 --> 00:00:28,880
would you breakdown news 
stories? 

8
00:00:28,880 --> 00:00:31,040
What's the point? 
When do we do it? 

9
00:00:31,240 --> 00:00:34,960
Why would we do it? 
And this applies no matter what 

10
00:00:34,960 --> 00:00:37,200
kind of project that you are 
running. 

11
00:00:37,400 --> 00:00:41,120
If you're running a pure agile 
shop, this applies to you. 

12
00:00:41,360 --> 00:00:46,280
If you're running a waterfall 
rigid approach and maybe an 

13
00:00:46,280 --> 00:00:50,440
organization that has a very 
clear business case framework, 

14
00:00:50,760 --> 00:00:53,760
or if you are somewhere in 
between the fragile framework, 

15
00:00:54,000 --> 00:00:57,040
somewhere in between, then this 
applies to you. 

16
00:00:57,040 --> 00:00:59,840
So this is, it doesn't really 
matter what methodology you're 

17
00:00:59,840 --> 00:01:03,440
using. 
And our job as ABA is to make 

18
00:01:03,440 --> 00:01:05,960
things clear. 
It is to make things concise. 

19
00:01:06,200 --> 00:01:11,240
It is to bridge communication 
across stakeholders and it is 

20
00:01:11,240 --> 00:01:14,000
part of the job. 
If you're wearing, and this 

21
00:01:14,000 --> 00:01:17,800
can't, just to be very clear, 
this can sometimes fall to a 

22
00:01:17,800 --> 00:01:21,600
product owner in a pure Scrum 
environment where they don't 

23
00:01:21,600 --> 00:01:24,960
really have ABA. 
So this applies to you, your job

24
00:01:24,960 --> 00:01:32,040
is to make sure that these user 
stories, these user stories are 

25
00:01:32,880 --> 00:01:37,360
are fluid, that they evolve that
that's OK and that you do that 

26
00:01:37,360 --> 00:01:42,040
though in a series of stages. 
You do this in pre project 

27
00:01:42,040 --> 00:01:43,520
stage. 
If you're involved in that or 

28
00:01:43,520 --> 00:01:45,720
our BA does that for you, that 
is ABA role. 

29
00:01:45,960 --> 00:01:48,080
You do this at the front of a 
project. 

30
00:01:48,080 --> 00:01:51,640
And I would say that that's also
ABA role, the high level 

31
00:01:52,160 --> 00:01:55,520
requirements phase before you 
get into development, whatever 

32
00:01:55,520 --> 00:01:57,600
you call that phase. 
And then there is the 

33
00:01:57,600 --> 00:02:02,280
development phase where either 
ABA or a very good, well trained

34
00:02:02,280 --> 00:02:06,480
product owner who has BA skills 
is doing this for you. 

35
00:02:06,640 --> 00:02:12,320
So let's get into it when you 
are in the pre delivery phase, 

36
00:02:12,320 --> 00:02:15,400
so you're not near development, 
right? 

37
00:02:15,400 --> 00:02:19,000
And, and, and I talk about this 
often, there is a phase, there's

38
00:02:19,000 --> 00:02:22,520
a pre project phase and even in 
the start of the project, once 

39
00:02:22,520 --> 00:02:24,760
the project's kicked off, 
there's a high level 

40
00:02:24,760 --> 00:02:26,960
requirements phase, whatever you
want to call it. 

41
00:02:27,280 --> 00:02:30,160
There's a phase that happens 
before you get everyone involved

42
00:02:30,480 --> 00:02:33,640
in the nitty gritty and then you
have the development phase. 

43
00:02:33,760 --> 00:02:37,400
OK, so that whatever method 
you're using, we have methods 

44
00:02:37,400 --> 00:02:41,440
here at the Better Business 
Analysis Institute, but whatever

45
00:02:41,440 --> 00:02:44,640
method you're conforming to, I'm
going to assume nothing here. 

46
00:02:45,040 --> 00:02:47,000
There are three different 
phases. 

47
00:02:47,000 --> 00:02:49,800
There is the phase before the 
project's kicked off 

48
00:02:49,800 --> 00:02:52,800
feasibility. 
There is a phase at the start of

49
00:02:52,800 --> 00:02:55,680
the project when you're doing 
high level work and then there 

50
00:02:55,680 --> 00:02:57,720
is a phase when you're doing 
detail work. 

51
00:02:57,720 --> 00:03:01,440
And that happens in the delivery
phase and the development phase.

52
00:03:02,000 --> 00:03:05,040
And so you'll use the stories 
need to cater for those needs 

53
00:03:05,320 --> 00:03:11,120
before you get into the project.
Your epic stories should be done

54
00:03:11,480 --> 00:03:16,000
and ideally you might have, you 
might have, and this is a might 

55
00:03:16,000 --> 00:03:19,760
now a very, very high level user
stories depending on the 

56
00:03:19,760 --> 00:03:23,520
complexity of your program. 
If the epics are just too big, 

57
00:03:24,080 --> 00:03:28,400
when I say too big, too big for 
someone in the management team 

58
00:03:28,400 --> 00:03:32,120
or the business ownership team 
to really understand what you're

59
00:03:32,120 --> 00:03:34,520
talking about, you may break it 
down further with examples, 

60
00:03:34,520 --> 00:03:36,720
which might be the start of your
high level user stories. 

61
00:03:37,080 --> 00:03:41,720
Depends on the size of the price
now in pre development. 

62
00:03:41,720 --> 00:03:45,160
So the phase, the high level 
requirements phase, I like to 

63
00:03:45,160 --> 00:03:47,800
call it, you are still 
understanding user needs. 

64
00:03:47,800 --> 00:03:50,960
You're contacting, you're doing 
workshopping, you're doing 

65
00:03:50,960 --> 00:03:52,280
interviews, you're doing 
surveys. 

66
00:03:52,480 --> 00:03:55,680
Things are very, very, very 
fluid at this stage, right? 

67
00:03:55,760 --> 00:03:59,040
And you're now talking about 
what we need to achieve when it 

68
00:03:59,040 --> 00:04:03,200
comes to those epics, which are 
a kind of, if you like our goals

69
00:04:03,560 --> 00:04:07,200
and we need to make sure our 
user stories accurately reflect 

70
00:04:07,200 --> 00:04:10,160
the needs and expectations of 
the end users and and 

71
00:04:10,160 --> 00:04:13,800
stakeholders ultimately, right. 
And so you are creating high 

72
00:04:13,800 --> 00:04:17,279
level user stories at the stage.
And I like to do that in Excel 

73
00:04:17,279 --> 00:04:21,680
before I put it into the Azure 
DevOps, for example. 

74
00:04:21,839 --> 00:04:25,720
That's just a tradition because 
it really says, hey, developers,

75
00:04:25,720 --> 00:04:27,360
I don't want to you to look at 
it. 

76
00:04:27,520 --> 00:04:31,840
But as those tools, Jira and 
DevOps become more of the BA 

77
00:04:31,920 --> 00:04:36,680
tool of choice, that you may 
well find that it it makes sense

78
00:04:36,680 --> 00:04:40,000
to start in that tool and just 
kind of flag them as such that 

79
00:04:40,000 --> 00:04:41,400
they're not, they're just in the
backlog. 

80
00:04:41,400 --> 00:04:43,160
Nothing to do with sprints at 
this point. 

81
00:04:44,080 --> 00:04:48,320
Now, when you are are describing
your high level user stories, 

82
00:04:48,680 --> 00:04:52,000
you want to be clear and 
concise, as I say often about 

83
00:04:52,000 --> 00:04:55,840
what the solution should be 
achieving from a user's 

84
00:04:55,840 --> 00:04:58,680
perspective. 
You are prioritizing those in 

85
00:04:58,680 --> 00:05:00,560
terms of masks, should, could 
and would. 

86
00:05:00,880 --> 00:05:03,120
Usually when you're in the 
development phase, people just 

87
00:05:03,120 --> 00:05:07,560
assume that everything in the 
backlog needs to be done at some

88
00:05:07,560 --> 00:05:08,840
point. 
And obviously in the Sprint 

89
00:05:08,840 --> 00:05:12,360
planning, you do what needs to 
be done now from a from a task 

90
00:05:12,360 --> 00:05:17,080
point of view in order to 
achieve the acceptance criteria 

91
00:05:17,080 --> 00:05:21,680
or the Sprint goal. 
But I think your Moscow rating 

92
00:05:21,680 --> 00:05:24,640
should have been applied with 
the product owner before you 

93
00:05:24,640 --> 00:05:28,680
even got into that phase. 
OK, so you, your job as ABA is 

94
00:05:28,680 --> 00:05:34,040
to focus on delivering the most 
critical parts of the job to be 

95
00:05:34,040 --> 00:05:38,920
done. 
Sometimes people talk about 

96
00:05:38,920 --> 00:05:42,760
features interchangeably and 
features is still a mystery in 

97
00:05:42,760 --> 00:05:43,960
terms of what that actually 
means. 

98
00:05:44,400 --> 00:05:48,800
And we, you know, and you can I 
avoid the word because it talks 

99
00:05:48,800 --> 00:05:51,440
about system functionality and 
so I avoid it. 

100
00:05:52,000 --> 00:05:54,400
But what I'm trying to say is 
the most critical jobs to be 

101
00:05:54,400 --> 00:05:58,520
done, things that need to be 
done like from a from a 

102
00:05:58,520 --> 00:06:03,080
customer's perspective or solid 
conceptual parts of the 

103
00:06:03,080 --> 00:06:07,360
solution, which could be cool 
features is your job is to make 

104
00:06:07,360 --> 00:06:10,840
sure that they are you are 
focusing on the ones that 

105
00:06:11,040 --> 00:06:16,880
maximize the value early on. 
OK, now you go, OK, well, I can 

106
00:06:16,880 --> 00:06:19,840
do that in Excel and I've got 
that in there. 

107
00:06:19,840 --> 00:06:23,400
I've got it in DevOps and I've 
sequenced them and I've talked 

108
00:06:23,400 --> 00:06:25,680
to my product owner or my 
business owner or I've put in, 

109
00:06:26,120 --> 00:06:29,080
put in my Moscow's, right? 
I'm done. 

110
00:06:29,880 --> 00:06:31,680
No, there's another lens you 
need to apply. 

111
00:06:32,160 --> 00:06:35,280
You need to do some story 
mapping, OK, And the story 

112
00:06:35,280 --> 00:06:38,760
mapping brings us all the way 
back to human centered design 

113
00:06:38,760 --> 00:06:40,600
and what you need to embrace as 
ABA. 

114
00:06:41,000 --> 00:06:46,400
You need to sequence these on a 
visual board, a whiteboarding 

115
00:06:46,400 --> 00:06:49,240
tool. 
OK, ideally a physical board 

116
00:06:49,240 --> 00:06:54,480
maybe behind where your project 
team sits is fantastic and you 

117
00:06:54,480 --> 00:06:58,960
need to throw those user stories
up and go if we if I was a 

118
00:06:58,960 --> 00:07:01,840
customer or a user who needed to
complete this job. 

119
00:07:02,040 --> 00:07:05,600
So from end to end, all the epic
steps, OK, in order to achieve 

120
00:07:05,600 --> 00:07:12,040
my goal, have other in gaps. 
Your job as the BA is to apply 

121
00:07:12,040 --> 00:07:17,160
logic and go actually we've 
totally missed a whole user 

122
00:07:17,160 --> 00:07:23,520
story or set of user stories 
around maybe if you're creating 

123
00:07:23,520 --> 00:07:26,800
a new report, we've totally not 
talked about the channel. 

124
00:07:26,960 --> 00:07:30,720
We've not talked about how we're
going to get the actual report 

125
00:07:31,440 --> 00:07:34,520
back to the user. 
There's a gap in your user story

126
00:07:34,520 --> 00:07:37,880
because and then your user 
journey to be honest, both 

127
00:07:38,200 --> 00:07:41,760
because you haven't talked about
that and if and then those if 

128
00:07:41,760 --> 00:07:44,960
you have a gap, assumptions will
be made and and the development 

129
00:07:44,960 --> 00:07:48,400
team will make those for you. 
OK, Or otherwise it may be too 

130
00:07:48,400 --> 00:07:51,680
late to think about that when 
you're mid development, when 

131
00:07:51,680 --> 00:07:53,760
you've actually not 
conceptualized or even had a 

132
00:07:53,760 --> 00:07:57,760
discussion about how much work 
would be involved in that. 

133
00:07:57,760 --> 00:08:01,160
I'm not talking about some 
Agilos might jump up and down 

134
00:08:01,160 --> 00:08:02,160
here and go. 
That's our job. 

135
00:08:02,760 --> 00:08:04,280
It's not not talking about your 
team. 

136
00:08:04,760 --> 00:08:07,080
I'm actually talking about maybe
there needs to be some user 

137
00:08:07,080 --> 00:08:10,520
workshops about how we do this 
feature. 

138
00:08:10,720 --> 00:08:14,160
They could, they could literally
take the same length as a few 

139
00:08:14,160 --> 00:08:16,480
sprints. 
OK, it could take months. 

140
00:08:17,000 --> 00:08:23,040
So you need to do that as ABA 
and be pretty damn happy that 

141
00:08:23,040 --> 00:08:26,480
you have identified all the gaps
or if there are gaps that the 

142
00:08:26,480 --> 00:08:29,960
product owner understands why 
the gaps and they're just not 

143
00:08:29,960 --> 00:08:32,120
important or you're not making a
change, right. 

144
00:08:32,440 --> 00:08:35,320
So if you just use, if the user 
story is to just use all the 

145
00:08:35,320 --> 00:08:39,200
channels you use today, great. 
OK, put, but explicitly put that

146
00:08:39,200 --> 00:08:41,120
in the as a user story. 
Even though you're not changing 

147
00:08:41,159 --> 00:08:44,480
it, it's really, really good to 
just mark them straight away as 

148
00:08:44,520 --> 00:08:47,760
out of scope or already done or 
done straight away. 

149
00:08:48,320 --> 00:08:50,320
OK, you haven't even talked to 
the development team, but you 

150
00:08:50,320 --> 00:08:53,360
know that that's already done. 
Or you would take them to the 

151
00:08:53,760 --> 00:08:56,560
first Sprint planning and go, we
know that these are the user 

152
00:08:56,560 --> 00:08:59,120
stories and they'll go, well, 
that we already have a, a way to

153
00:08:59,120 --> 00:09:00,960
solve that and solve that and 
solve that. 

154
00:09:00,960 --> 00:09:04,160
It's to reuse what we've got and
you'll go, great, cool, done. 

155
00:09:04,480 --> 00:09:06,080
But then you've actually got a 
trial. 

156
00:09:06,080 --> 00:09:08,960
And then you can see where the 
gaps are in that visual user 

157
00:09:08,960 --> 00:09:14,080
story and which ones have been 
fulfilled by reusing functions 

158
00:09:14,080 --> 00:09:16,400
or features that you already 
have around the organization or 

159
00:09:16,400 --> 00:09:18,000
current state. 
If you like, you're not changing

160
00:09:18,000 --> 00:09:21,360
the current state. 
Finally, in the development 

161
00:09:21,360 --> 00:09:26,080
phrase, this is where you take 
whatever user stories, high 

162
00:09:26,080 --> 00:09:28,640
level user stories you have and 
generally probably be one level.

163
00:09:28,640 --> 00:09:31,320
They may have child user stories
at this point, depending on 

164
00:09:31,320 --> 00:09:36,680
complexity and you'll decompose 
them in the proper Scrum way of 

165
00:09:36,680 --> 00:09:40,440
decomposing an agile way where 
you are decomposing the user 

166
00:09:40,440 --> 00:09:44,480
stories from the perspective of 
the doers and the doers, the 

167
00:09:44,480 --> 00:09:47,840
development team, the delivery 
team are going, oh man, that's 

168
00:09:47,840 --> 00:09:48,760
that. 
Use a story there. 

169
00:09:48,760 --> 00:09:51,080
That's quite a chunky one. 
I want to break that down. 

170
00:09:51,080 --> 00:09:53,800
I need that to be clearer. 
And so you and that's OK. 

171
00:09:53,800 --> 00:09:58,280
It's you haven't just gone. 
Sorry guys, this can't change. 

172
00:09:59,120 --> 00:10:02,400
You've got it in the words of 
the of the product owner at this

173
00:10:02,400 --> 00:10:05,960
stage, they understand. 
So your job is to then help work

174
00:10:05,960 --> 00:10:08,880
out how you'd break that down. 
And there are some good tricks 

175
00:10:08,880 --> 00:10:10,760
for this. 
Again, I could speak about this 

176
00:10:10,760 --> 00:10:13,040
for hours, but I won't. 
This is a bite. 

177
00:10:13,680 --> 00:10:21,840
If you have a user story, right?
And it's, I'll make one up as a 

178
00:10:23,120 --> 00:10:27,320
reporting user, OK, that's not 
really descriptive, but I'm just

179
00:10:27,320 --> 00:10:29,440
going to use that as this case. 
We're going to be an internal 

180
00:10:29,440 --> 00:10:32,040
user. 
As a reporting user, I would 

181
00:10:32,040 --> 00:10:41,440
like to view and receive a copy 
of the new payroll performance 

182
00:10:41,440 --> 00:10:47,680
report every Sunday so that I 
can continue my steps on a 

183
00:10:47,680 --> 00:10:50,440
Monday to review that and do my 
job right. 

184
00:10:50,720 --> 00:10:54,200
That very loose, not well 
thought of off the spot, but 

185
00:10:54,320 --> 00:10:55,680
that's great. 
It's a high level one. 

186
00:10:56,080 --> 00:10:57,720
Check that into DevOps and work 
with it. 

187
00:10:57,720 --> 00:11:00,160
You're not the you don't have to
be the best writer in the world.

188
00:11:00,160 --> 00:11:02,600
You just work with the product 
owner and make sure it and 

189
00:11:02,920 --> 00:11:04,640
you've articulated what they 
want. 

190
00:11:05,360 --> 00:11:08,760
And that's why you have another 
side top tip. 

191
00:11:09,080 --> 00:11:12,800
That's why you'll use the story 
name, your description, the what

192
00:11:12,800 --> 00:11:14,560
you've just talked about is 
different to the description. 

193
00:11:14,560 --> 00:11:17,440
Some people argue that the 
description is acceptance 

194
00:11:17,440 --> 00:11:19,360
criteria. 
I think it's actually just 

195
00:11:19,360 --> 00:11:22,520
really defining what you mean by
that statement and acceptance 

196
00:11:22,520 --> 00:11:25,240
criteria separate or underneath 
the description. 

197
00:11:25,600 --> 00:11:28,800
So you've got that right. 
And you say, well that's great 

198
00:11:28,800 --> 00:11:32,120
user story, totally understand 
what that means at a high level.

199
00:11:32,120 --> 00:11:34,240
You go into the development 
phase and the development team 

200
00:11:34,240 --> 00:11:39,560
goes, OK, so you want us to be 
able to allow them to have 

201
00:11:39,560 --> 00:11:46,280
access and you're like, yes, OK,
you want them to be notified and

202
00:11:46,280 --> 00:11:50,320
you're like, Yep. 
And maybe you want them to 

203
00:11:50,320 --> 00:11:54,040
subscribe to the report because 
our features or their they are 

204
00:11:54,040 --> 00:11:58,040
features that we can provide 
with maybe our architectural 

205
00:11:58,040 --> 00:11:59,960
reporting tool that we've 
already got. 

206
00:12:00,400 --> 00:12:02,680
And there is no requirements to 
suggest we're going out to 

207
00:12:02,680 --> 00:12:04,520
market or changing that. 
And you're like, yeah, 

208
00:12:04,800 --> 00:12:06,960
completely agree. 
When we write that, we just 

209
00:12:06,960 --> 00:12:09,160
assume that we're going to use 
Power BI because we've got that 

210
00:12:09,160 --> 00:12:11,320
and they're like, OK, Yep, 
confirmed. 

211
00:12:11,320 --> 00:12:15,320
We will, unless there's a 
requirement, suggest otherwise. 

212
00:12:15,720 --> 00:12:18,560
So could you break that user 
story down just to be really 

213
00:12:18,560 --> 00:12:21,120
clear? 
And to three, what we would like

214
00:12:21,120 --> 00:12:26,320
to know is who needs access 
where they would review, view 

215
00:12:26,320 --> 00:12:30,520
that report, right? 
And the other one could be user 

216
00:12:30,520 --> 00:12:33,200
story around scheduling. 
So that one user story that you 

217
00:12:33,200 --> 00:12:35,440
had to start off with, you've 
broken down into three. 

218
00:12:35,880 --> 00:12:38,880
And one way to do it just to get
rid of the original user story 

219
00:12:39,440 --> 00:12:42,000
and have three new user stories,
right? 

220
00:12:42,880 --> 00:12:46,200
Or create a child user stories. 
So you have evolved that one 

221
00:12:46,200 --> 00:12:49,600
user story into three, right? 
And the one parent user story 

222
00:12:49,600 --> 00:12:51,560
encapsulates those three 
functions. 

223
00:12:52,120 --> 00:12:56,320
Now that the only reason you 
would break down into child user

224
00:12:56,320 --> 00:13:00,240
stories and not just, you know, 
basically superseded Evolver 

225
00:13:00,320 --> 00:13:04,120
from 1:00 to 3:00 is if you had 
intense traceability backup, 

226
00:13:04,240 --> 00:13:07,480
right? 
So I do like, and it's only 

227
00:13:07,480 --> 00:13:10,280
recent time where I've started 
to use the concept of child user

228
00:13:10,280 --> 00:13:13,400
stories and then mark that top 
one as being apparent. 

229
00:13:13,520 --> 00:13:15,640
And you could say, well, that's 
an epic because you're breaking 

230
00:13:15,640 --> 00:13:17,640
it down. 
It isn't an epic because you 

231
00:13:17,640 --> 00:13:19,840
can. 
An epic is an ultimate goal that

232
00:13:19,840 --> 00:13:24,200
should encompass a whole lot of 
views and it comes from the view

233
00:13:24,200 --> 00:13:27,040
of the product owner of the 
business, not from the 

234
00:13:27,040 --> 00:13:28,840
development team. 
What's easier for them to do 

235
00:13:28,840 --> 00:13:33,680
tasks equally as I've seen also 
done before, as the user story 

236
00:13:33,680 --> 00:13:36,320
remains and it has three 
acceptance criteria, which are 

237
00:13:36,320 --> 00:13:38,400
the three functional areas 
you're talking about. 

238
00:13:38,680 --> 00:13:41,240
And it really depends on the 
preference and pattern you use 

239
00:13:41,240 --> 00:13:44,200
in the development phase. 
OK, when you define your 

240
00:13:44,200 --> 00:13:46,600
acceptance criteria, there are 
conditions in which the user 

241
00:13:46,600 --> 00:13:51,080
story is considered complete. 
You they those acceptance 

242
00:13:51,080 --> 00:13:53,480
criteria. 
Just be really clear here. 

243
00:13:53,840 --> 00:13:56,320
If you're using the acceptance 
criteria to define those 

244
00:13:56,320 --> 00:13:59,440
different functions, completely 
separate functions that add up 

245
00:13:59,440 --> 00:14:03,320
to one experience, that testers 
will use those acceptance 

246
00:14:03,320 --> 00:14:05,720
criteria. 
So you need to predefine which 

247
00:14:05,720 --> 00:14:07,800
way you're doing this, not 
midway through. 

248
00:14:08,240 --> 00:14:12,400
OK, so if the user is going to 
create test cases, if you're 

249
00:14:12,400 --> 00:14:15,000
breaking down into child user 
stories for each function, the 

250
00:14:15,000 --> 00:14:17,440
test cases will come straight 
off the child because it will be

251
00:14:17,440 --> 00:14:21,400
1 acceptance criteria per child.
If you're doing more of a bundle

252
00:14:21,400 --> 00:14:24,400
because it makes more sense 
though, and the development team

253
00:14:24,400 --> 00:14:27,520
are not dummies, they should 
understand the the user journey 

254
00:14:27,520 --> 00:14:31,480
here for both viewing, receiving
and scheduling a report. 

255
00:14:32,800 --> 00:14:36,160
They you could have the three 
acceptance criteria and the one 

256
00:14:36,160 --> 00:14:40,160
user story, but then you would 
you would have at least three 

257
00:14:40,360 --> 00:14:42,680
test cases under that. 
And again, test cases have 

258
00:14:42,680 --> 00:14:45,400
hierarchies. 
There could be a test case at a 

259
00:14:45,400 --> 00:14:48,920
high level, and then they can be
broken down into smaller tests 

260
00:14:48,920 --> 00:14:51,800
or smaller actions. 
Do you need consistency there? 

261
00:14:52,280 --> 00:14:56,400
And of course, you continuously 
refine this. 

262
00:14:56,400 --> 00:15:00,240
Every review, every backlog 
refinement, every time you go 

263
00:15:00,240 --> 00:15:03,840
into the Sprint plan, they can 
adapt and you need to adapt the 

264
00:15:03,840 --> 00:15:05,760
user stories. 
And that's why I like that. 

265
00:15:05,840 --> 00:15:08,680
Keeping that traceability, 
definitely the ID number should 

266
00:15:08,680 --> 00:15:11,320
be traceable all the way up to 
the epoch being the front of the

267
00:15:11,320 --> 00:15:14,000
user story, you know, So if 
you've got an epic one, your 

268
00:15:14,000 --> 00:15:17,920
user story should be 1.1. 
OK, That's how I control that. 

269
00:15:18,880 --> 00:15:22,280
It helps really. 
User stories help us as a 

270
00:15:22,280 --> 00:15:25,480
communication tool to talk about
changes and, and how they've 

271
00:15:25,480 --> 00:15:27,320
evolved. 
And a project manager might 

272
00:15:27,320 --> 00:15:29,520
freak out and go, we started 
with 10 user stories and now 

273
00:15:29,520 --> 00:15:31,760
we've got fifty. 
Well, that's just normal. 

274
00:15:31,920 --> 00:15:36,080
And so after that initial 
review, the initial planning 

275
00:15:36,080 --> 00:15:38,000
stage, and I know you're 
supposed to go straight to 

276
00:15:38,000 --> 00:15:41,120
sprints, but as you're doing 
backlog refinement, you should 

277
00:15:41,120 --> 00:15:44,880
have a pretty good idea after 
the maybe Sprint one or two, how

278
00:15:44,880 --> 00:15:48,800
many kind of user stories you're
going to have, OK, it will start

279
00:15:48,800 --> 00:15:50,840
giving you an idea if you start 
breaking them down. 

280
00:15:50,840 --> 00:15:52,640
That's all part of agile. 
That's the whole point. 

281
00:15:52,640 --> 00:15:55,160
So you can't just go the project
manager's freaking out that you 

282
00:15:55,160 --> 00:15:56,760
started with 100 and now you've 
got 200. 

283
00:15:56,760 --> 00:15:59,400
Well, that's just the nature of 
deciding to run your project in 

284
00:15:59,400 --> 00:16:03,000
an agile way. 
OK, You can use that to track 

285
00:16:03,000 --> 00:16:06,520
progress, obviously, and see how
things are going. 

286
00:16:07,000 --> 00:16:10,280
And yeah, don't I guess I just 
want to leave you with the 

287
00:16:10,880 --> 00:16:13,960
thought that it, it feels 
sometimes wrong breaking down 

288
00:16:13,960 --> 00:16:15,880
your user stories. 
It kind of feels like, oh man, 

289
00:16:15,880 --> 00:16:18,320
I've just perfected these user 
stories, I've captured them and 

290
00:16:18,320 --> 00:16:20,480
now you're breaking them up. 
As long as you have the 

291
00:16:20,480 --> 00:16:22,840
traceability, that is their 
purpose, OK? 

292
00:16:22,880 --> 00:16:25,440
They're not supposed to be the 
beyond end all. 

293
00:16:25,560 --> 00:16:27,160
What doesn't change are your 
epics. 

294
00:16:27,480 --> 00:16:29,160
OK? 
And if they do change, sorry, 

295
00:16:29,160 --> 00:16:33,360
epics can change, but that would
be with a major change to your 

296
00:16:33,800 --> 00:16:38,040
to your project scope. 
And if you're using the breaking

297
00:16:38,040 --> 00:16:40,520
down as the children user 
stories approach, which is my 

298
00:16:40,520 --> 00:16:43,760
preference, then you could save 
those high level user stories 

299
00:16:43,760 --> 00:16:45,560
change. 
You need to do a change for a 

300
00:16:45,640 --> 00:16:48,920
request for change. 
OK guys, I will see you next 

301
00:16:48,920 --> 00:16:50,520
week. 
I hope you learned something 

302
00:16:50,520 --> 00:16:51,040
this week.