📺 Develpreneur YouTube Episode

Video + transcript

An Overview of Scrum Roles

2023-05-23 •Youtube

Detailed Notes

This is an overview from one of our Agile classes (https://school.develpreneur.com/p/software_development_life_cycle).

You can find out more through our online classes at https://school.develpreneur.com and register for free. Registration will add you to our email list and you will periodically receive coupons for courses as well as notifications of the latest releases.

Transcript Text
thank you
[Music]
welcome back and today in this episode
we're going to talk a little bit about
scrum rolls we've been around we've beat
around the bush on this a little bit we
have actually run some classes or some
courses in the past and I think it's
good to just sort of like do a review of
these make sure that we're clear on what
is it that what are the people the roles
that make up a scrum team
so we want to talk about the positions
the roles the titles as it were
but these all all these roles roll into
this scrum team so if you're doing scrum
if you're using agile scrum then you
have a team these are the people that
make that team up there are three key
roles for a scrum team there is the
product owner the scrum master and the
development team now that seems may seem
a little confusing because it said you
know I just said this is the scrum team
but within there is the development team
but that is a critical I will say
distinction is the difference between
your scrum team and the development team
and this is basically because your
product owner is a single person your
scrum Master single person the
development team is a group of people
but they don't have
specific labels you don't have a
JavaScript developer or QA or database
administrator it is just the development
team
we'll talk about more about them just
here in a little bit
let's start with the product owner
the product owner is responsible for the
solution this is your representative of
the final customer one this is the
person that is going to make decisions
that are going to help you basically
build the solution that works for
whatever those customers are there's a
couple ways they do that
they are going to decide what to do this
is a matter of do we put this feature in
or not do we enhance it in this way how
do we move forward with this you know
application that we have Sitting where
we're at
such your product owner is
the customer is the the subject matter
expert for your solution
and so they're going to help you at you
being the team they're going to help the
team figure out what is it that makes
this solution worthwhile what is it that
brings value to our customers and along
with that throw out things that are not
if it's just a bell and a whistle that's
not very helpful then the product owner
is going to say let's let's not worry
about that
in a typical Sprint approach though when
you've got a scrum team
they are driving towards certain goals
along the way there may be within a
single Sprint a you know a theme or a
goal or an objective but there's also
going to be longer term things that are
going to take a couple of Sprints and
this may be something like a I will call
like a version 1.0 release that we're
working towards or a maybe a minimally
viable product an MVP that we are
working towards as we're building these
Sprints we're going through these
Sprints we're building an application
we're building a solution and the
product owner is going to help us decide
what needs to be in that that first or
this next release and what are things
that we can push off into the future
that they can come back later they're
not as important and they don't do this
in a vacuum this is why it's a team but
the key to or the product owners they
are to the decision maker you have a
team but at some point somebody has to
decide yes we're going to do that or no
we're not going to do or this is
important or this is not important
that is what your product owner does
the next role I want to talk about is
the scrum Master this is effectively the
coach for the team
the goal of the scrum Master is to make
the team better
in doing so they're going to help the
team work better through removing
obstacles whether it's the development
team or the product owner the
development team more often is going to
have obstacles it may be things like
there is uh maybe there's some licensing
issues that they have to get worked out
so that they can use their tools or
there may be questions that are blocking
them
they may need answers to certain
questions in order to have the proper
requirements the details in order to
implement whatever needs to be
implemented now if it's directly
something that the product owner can
deal with a lot of times it's just
that's part of the the team meetings and
the conversations and then all you have
to worry about is the product owner
answering the questions but there are
times when that's not the case
and this may even include team members
that are
we will say blocked or utilized by other
other projects other resources and
things like that there may be for
example within the team you do your
regular status and things like that but
there may be an over arching business or
organization status reporting that needs
to be done and maybe that's taking a lot
of time because of how the Sprint's
going so maybe the scrum Master helps
find a way to get that stuff moved or
changed or simplified
and this can take a broad range of
realities that there's a lot of ways
that this can this can actually be done
as a scrum Master it may be
conversations with people it may be
research it may be acquiring certain
things and this is for the product owner
as well so there may be things like the
product owner is trying to get a
decision and needs somebody else to
Rattle a cage so somebody gets an answer
or there may be a lot of research the
product owner needs to do in order to
properly build out the backlog and the
scrum Master may be a part of that
so they are
sort of a player coach in a sense
because the scrum Master may do work
here and there but it's really
more a a managing coach more of a
coaching and helping the team get stuff
out of the way and do the processes
better and within the process the actual
process of scrum this is where the scrum
Master is going to make sure that people
stay on track that they follow the
agenda that's set that they are
utilizing the tools properly so they are
for example making sure that tasks get
properly built into the backlog
that tests are updated properly once
they're in the backlog when the team's
working on them that tasks have a a
clearly defined done set of criteria or
state you know something that says we
have completed this
and then the the scrum Master is also
going to work with and we'll talk in
other
situations we're going to get a little
bit more into some of the the rituals
and the activities that occur in a scrum
or you can see that in in some of our
other posts that are out there
but the scrum Master is going to make
sure that those activities like for
example your daily stand-up that they
work and they are utilized properly so
that your daily stand-up for example is
done quickly you get what you need out
of it and you move on to work and it
doesn't turn into an hour-long meeting
that sucks the whole team in every day
so your scrum Master is the one at the
end of all of this that you look at and
say they either yes helped the process
and the team get better or they didn't
and in which case they're that's part of
their own thing they're going to help
even themselves look at ways that in
that next Sprint in that next iteration
that they can do things better
the development team is not just a
person it is a team it typically in a
scrum it's going to be three to maybe
nine members so it's not real small it's
not gonna be one person it's not gonna
be two because you need to have at least
usually three to have enough people
working enough resources available to
make the Sprint work to make scrum
useful otherwise it ends up being
overhead that's not really needed
these are the the implementers the
development team are the people that get
the job done that make the product that
do the coding that do the testing that
they do the deployment these are going
to be your technical members
and note in scrum it is a development
team it is not a junior developer and a
UI developer and a tester that is
critical in properly doing scrum yes
you're going to have people almost every
time there's gonna be certain people
that are going to be best suited for
specific tasks and there may even be
Specialists of some sort where they
really are the one that needs to do that
task however your goal over time
is for there to be
cross-training and general knowledge
about the system that allows you to Plug
and Play people into any task and
there's so many reasons that that is
valuable the least of which is that then
you're not a slave in a given Sprint to
somebody you know getting sick or taking
a week off or two weeks off or something
like that where
if you don't have that then you may have
some critical resource you know a senior
developer that is not available and now
you have a whole handful of tasks that
can't be done because that developer is
not available that is what you want to
avoid now again the reality is that that
happens more often than not that that is
a fairly regular situation but as a
scrum Master that's one of the things
you want to work for is try to find some
sort of you know cross-training and ways
to get everybody working towards this
goal which is the whole idea of what a
scrum is is get the whole team pushing
forward pushing in the same direction
working together so that that difference
in experience and knowledge and
technical skills can be shrunk a little
bit so that you can find a way for even
your newest developers To Be steady and
regular contributors hopefully across
whatever test get is Task it is that
they are working on
this team this development team just to
be clear these are the people that write
the code they design stuff they do
testing they do deployment they are
really going to drive your estimates and
they're going to give technical feedback
your product owner is a business person
for the most part now they will
potentially have technical Knowledge and
Skills but their focus is the business
side
the development team is the technical
side and they are best working when they
work with the product owner to help them
understand what is the cost what is the
investment what is the risk to all of
these different tasks and the priorities
that are being set
so while the product owner is going to
really set the course in a sense is
going to be setting priorities and
setting tasks the development team
should be a part of that and give
technical feedback to help the product
owner make decisions that are well
informed
at the end of this it is key to
understand this is a team
the scrum team should work together and
they should be looking at ways to
incrementally improve and that increment
being by Sprint basically the way they
build the solution they're building and
if they go beyond that where they build
Solutions in general
the whole goal as you step into this as
a team is to say this is something we
want to solve this is where we're at and
then each time you go through it you
want to be able to do better so that
where you say this is where we're at
that should be in a better situation a
better place after every single scrum
that is
in a nutshell the roles and the you know
really the objective of scrum is you've
got your product owner you've got scrum
Master you got your development team
they work together and if they do it
right they're going to build a great
solution and they're going to be better
at doing it when they get to that last
Sprint than they were at the first one
[Music]
Transcript Segments
11.66

thank you

18.89

[Music]

25.82

welcome back and today in this episode

29.4

we're going to talk a little bit about

30.84

scrum rolls we've been around we've beat

34.86

around the bush on this a little bit we

37.079

have actually run some classes or some

38.88

courses in the past and I think it's

41.399

good to just sort of like do a review of

43.739

these make sure that we're clear on what

46.2

is it that what are the people the roles

49.14

that make up a scrum team

51.96

so we want to talk about the positions

55.5

the roles the titles as it were

58.68

but these all all these roles roll into

62.1

this scrum team so if you're doing scrum

64.92

if you're using agile scrum then you

67.799

have a team these are the people that

70.5

make that team up there are three key

73.619

roles for a scrum team there is the

76.74

product owner the scrum master and the

79.979

development team now that seems may seem

83.04

a little confusing because it said you

84.54

know I just said this is the scrum team

86.34

but within there is the development team

88.92

but that is a critical I will say

92.759

distinction is the difference between

95.479

your scrum team and the development team

98.64

and this is basically because your

101.1

product owner is a single person your

102.96

scrum Master single person the

105.18

development team is a group of people

107.52

but they don't have

109.439

specific labels you don't have a

112.56

JavaScript developer or QA or database

115.799

administrator it is just the development

118.32

team

119.22

we'll talk about more about them just

121.2

here in a little bit

123.42

let's start with the product owner

125.7

the product owner is responsible for the

129.239

solution this is your representative of

133.2

the final customer one this is the

136.68

person that is going to make decisions

139.98

that are going to help you basically

142.5

build the solution that works for

144.599

whatever those customers are there's a

146.819

couple ways they do that

149.16

they are going to decide what to do this

152.94

is a matter of do we put this feature in

155.7

or not do we enhance it in this way how

158.58

do we move forward with this you know

162.42

application that we have Sitting where

164.519

we're at

166.56

such your product owner is

170.7

the customer is the the subject matter

174.12

expert for your solution

176.76

and so they're going to help you at you

179.4

being the team they're going to help the

180.84

team figure out what is it that makes

183.3

this solution worthwhile what is it that

185.7

brings value to our customers and along

189.239

with that throw out things that are not

191.28

if it's just a bell and a whistle that's

193.379

not very helpful then the product owner

196.62

is going to say let's let's not worry

198.06

about that

199.319

in a typical Sprint approach though when

202.26

you've got a scrum team

203.94

they are driving towards certain goals

207.959

along the way there may be within a

211.08

single Sprint a you know a theme or a

213.659

goal or an objective but there's also

215.819

going to be longer term things that are

217.92

going to take a couple of Sprints and

219.84

this may be something like a I will call

222.12

like a version 1.0 release that we're

224.76

working towards or a maybe a minimally

227.76

viable product an MVP that we are

229.86

working towards as we're building these

231.54

Sprints we're going through these

232.92

Sprints we're building an application

234.959

we're building a solution and the

237.299

product owner is going to help us decide

239.7

what needs to be in that that first or

242.94

this next release and what are things

244.98

that we can push off into the future

247.2

that they can come back later they're

249.239

not as important and they don't do this

252.12

in a vacuum this is why it's a team but

255.36

the key to or the product owners they

257.88

are to the decision maker you have a

260.16

team but at some point somebody has to

261.72

decide yes we're going to do that or no

263.46

we're not going to do or this is

265.44

important or this is not important

267.9

that is what your product owner does

271.74

the next role I want to talk about is

273.479

the scrum Master this is effectively the

276.72

coach for the team

278.28

the goal of the scrum Master is to make

281.34

the team better

283.8

in doing so they're going to help the

285.66

team work better through removing

287.46

obstacles whether it's the development

289.62

team or the product owner the

291.479

development team more often is going to

293.04

have obstacles it may be things like

295.259

there is uh maybe there's some licensing

297.84

issues that they have to get worked out

300.12

so that they can use their tools or

302.52

there may be questions that are blocking

305.699

them

306.78

they may need answers to certain

308.34

questions in order to have the proper

310.44

requirements the details in order to

312.36

implement whatever needs to be

314.4

implemented now if it's directly

316.74

something that the product owner can

318.36

deal with a lot of times it's just

320.22

that's part of the the team meetings and

322.56

the conversations and then all you have

324.66

to worry about is the product owner

327.12

answering the questions but there are

329.28

times when that's not the case

331.38

and this may even include team members

334.44

that are

336.9

we will say blocked or utilized by other

341.22

other projects other resources and

344.039

things like that there may be for

346.38

example within the team you do your

349.139

regular status and things like that but

350.82

there may be an over arching business or

354.66

organization status reporting that needs

357.12

to be done and maybe that's taking a lot

359.22

of time because of how the Sprint's

360.78

going so maybe the scrum Master helps

363.24

find a way to get that stuff moved or

366.24

changed or simplified

368.46

and this can take a broad range of

373.82

realities that there's a lot of ways

376.32

that this can this can actually be done

378.419

as a scrum Master it may be

381.18

conversations with people it may be

382.919

research it may be acquiring certain

385.02

things and this is for the product owner

387.3

as well so there may be things like the

389.88

product owner is trying to get a

391.68

decision and needs somebody else to

394.979

Rattle a cage so somebody gets an answer

396.96

or there may be a lot of research the

399.66

product owner needs to do in order to

402.419

properly build out the backlog and the

406.139

scrum Master may be a part of that

409.02

so they are

410.58

sort of a player coach in a sense

412.979

because the scrum Master may do work

415.8

here and there but it's really

417.78

more a a managing coach more of a

421.199

coaching and helping the team get stuff

423.72

out of the way and do the processes

426.3

better and within the process the actual

429.419

process of scrum this is where the scrum

432.84

Master is going to make sure that people

434.28

stay on track that they follow the

437.34

agenda that's set that they are

439.88

utilizing the tools properly so they are

442.68

for example making sure that tasks get

446.039

properly built into the backlog

448.979

that tests are updated properly once

451.199

they're in the backlog when the team's

452.699

working on them that tasks have a a

455.94

clearly defined done set of criteria or

459.78

state you know something that says we

461.34

have completed this

463.259

and then the the scrum Master is also

465.539

going to work with and we'll talk in

467.52

other

468.66

situations we're going to get a little

470.58

bit more into some of the the rituals

473.46

and the activities that occur in a scrum

475.259

or you can see that in in some of our

476.94

other posts that are out there

478.68

but the scrum Master is going to make

480.3

sure that those activities like for

482.58

example your daily stand-up that they

484.74

work and they are utilized properly so

486.78

that your daily stand-up for example is

489.12

done quickly you get what you need out

491.099

of it and you move on to work and it

492.72

doesn't turn into an hour-long meeting

494.52

that sucks the whole team in every day

498.12

so your scrum Master is the one at the

500.759

end of all of this that you look at and

503.099

say they either yes helped the process

506.28

and the team get better or they didn't

509.16

and in which case they're that's part of

511.379

their own thing they're going to help

512.279

even themselves look at ways that in

515.279

that next Sprint in that next iteration

517.26

that they can do things better

521.459

the development team is not just a

525.48

person it is a team it typically in a

527.88

scrum it's going to be three to maybe

530.339

nine members so it's not real small it's

533.04

not gonna be one person it's not gonna

534.12

be two because you need to have at least

535.8

usually three to have enough people

538.68

working enough resources available to

541.92

make the Sprint work to make scrum

544.68

useful otherwise it ends up being

548.06

overhead that's not really needed

551.339

these are the the implementers the

554.22

development team are the people that get

555.72

the job done that make the product that

558.24

do the coding that do the testing that

560.1

they do the deployment these are going

562.56

to be your technical members

564.48

and note in scrum it is a development

568.38

team it is not a junior developer and a

571.5

UI developer and a tester that is

574.56

critical in properly doing scrum yes

578.88

you're going to have people almost every

581.22

time there's gonna be certain people

582.42

that are going to be best suited for

584.22

specific tasks and there may even be

587.6

Specialists of some sort where they

590.04

really are the one that needs to do that

592.5

task however your goal over time

597.18

is for there to be

599.12

cross-training and general knowledge

603.6

about the system that allows you to Plug

607.019

and Play people into any task and

610.62

there's so many reasons that that is

612.12

valuable the least of which is that then

614.64

you're not a slave in a given Sprint to

618.12

somebody you know getting sick or taking

620.459

a week off or two weeks off or something

622.5

like that where

624.54

if you don't have that then you may have

626.16

some critical resource you know a senior

629.3

developer that is not available and now

632.519

you have a whole handful of tasks that

634.32

can't be done because that developer is

636.779

not available that is what you want to

639.06

avoid now again the reality is that that

642.66

happens more often than not that that is

645.6

a fairly regular situation but as a

648.899

scrum Master that's one of the things

650.88

you want to work for is try to find some

653.279

sort of you know cross-training and ways

655.32

to get everybody working towards this

659.04

goal which is the whole idea of what a

661.44

scrum is is get the whole team pushing

663.42

forward pushing in the same direction

665.36

working together so that that difference

669.42

in experience and knowledge and

672.66

technical skills can be shrunk a little

675.42

bit so that you can find a way for even

677.76

your newest developers To Be steady and

681.36

regular contributors hopefully across

683.76

whatever test get is Task it is that

685.92

they are working on

688.74

this team this development team just to

691.38

be clear these are the people that write

693

the code they design stuff they do

695.22

testing they do deployment they are

697.62

really going to drive your estimates and

699.779

they're going to give technical feedback

701.64

your product owner is a business person

704.7

for the most part now they will

706.14

potentially have technical Knowledge and

708.06

Skills but their focus is the business

711.36

side

712.5

the development team is the technical

715.14

side and they are best working when they

718.56

work with the product owner to help them

720.48

understand what is the cost what is the

722.76

investment what is the risk to all of

726

these different tasks and the priorities

727.74

that are being set

729.839

so while the product owner is going to

731.579

really set the course in a sense is

733.5

going to be setting priorities and

735.24

setting tasks the development team

737.04

should be a part of that and give

738.899

technical feedback to help the product

740.7

owner make decisions that are well

743.519

informed

746.1

at the end of this it is key to

748.68

understand this is a team

750.42

the scrum team should work together and

753.54

they should be looking at ways to

754.68

incrementally improve and that increment

756.66

being by Sprint basically the way they

759.66

build the solution they're building and

761.88

if they go beyond that where they build

763.68

Solutions in general

765.839

the whole goal as you step into this as

768.6

a team is to say this is something we

771.42

want to solve this is where we're at and

774.6

then each time you go through it you

776.639

want to be able to do better so that

779.279

where you say this is where we're at

781.079

that should be in a better situation a

783.72

better place after every single scrum

786.74

that is

789.36

in a nutshell the roles and the you know

792.42

really the objective of scrum is you've

794.579

got your product owner you've got scrum

796.26

Master you got your development team

798.6

they work together and if they do it

801

right they're going to build a great

802.74

solution and they're going to be better

804

at doing it when they get to that last

805.62

Sprint than they were at the first one

807.72

[Music]