Transcripts
1. Scrum Masterclass Intro Video: I I'm Anna Bromley, an agile
practitioner who's helped teams streamline their workflows and deliver high
quality results. This course will allow you
to adapt swiftly to change, boost collaboration, and focus on satisfying customer needs. A while smashing your
project targets, you'll gain practical skills to confidently manage sprints, engage stakeholders,
and lead teams that produce reliable
outcomes every time. The course is designed around clear modules covering
the core Agile values, the 12 agile principles,
essential scrum roles, key scrum events, and scrum
artifacts and implementation. I created this course for
people who work on projects, team leaders and
engineers alike. I created it so that people
like you could understand the agile essentials
without committing to a full certification
path just yet. Maybe you aim to deliver
quicker releases or you worry about shifting requirements and
tight deadlines. These lessons will tackle
those real world challenges and give you the confidence and adaptability you
need to succeed. Thank you for considering Agile and Scrum
fundamentals Enroll Now.
2. Agile Intro : Hello, everyone, and welcome to my Agile and
Scrum master class. My name is Anna Bromley, and I am the owner and program consultant for
Agile Project Delivery. I have been working in project management
for over a decade. My background is I
was brought up in a retail environment and then started in sales and marketing. I then studied marketing
at university, entered into marketing roles, and then went on to transition
into project management. After I'd studied a
module at university, and I've been managing
large projects and programs for enterprise size customers
ever since, basically. So this is my training
that I've put together, and I'll just take you
through the agenda now. So I'm going to be talking about two areas here, Agile and Scrum. So within Agile, I'm going to talk about the
values and principles. And then within Scrum, which is a delivery methodology, which is an agile
delivery methodology. I'm going to be talking
about accountabilities and then key
artifacts and events. Just going to turn my
pointer on so it's easier. So what do I want you to
get out of this course? I would like you
to understand what the core agile values
are and be able to differentiate them between agile and more traditional
project management approaches often called waterfall. There's 12 agile principles. I would like you to understand those able to actually
implement agile practices, both in your personal life and in your professional
work as well. I think Agile will allow you to improve your collaboration
and communication. It will definitely enhance
your customer focus because it puts a lot more of
the focus on the end user. And the benefits of understanding
this way of working is you'll find that you can become more adaptable to change, which is important in this environment that we
live and work in these days, that your collaboration
will go up, that your customers
should be more satisfied, that you will find
greater efficiencies and productivity within
your delivery workflows, that your deliverables
will be higher. And this methodology allows you to make informed
decision making. Indeed, it yields more data, which allows you to
make better decisions. And it also leads to sustainable
development as well. So it allows you to deliver
a pace, but consistently. So that's the objectives and benefits of learning
about Agile and Scrum.
3. Agile Values: So let's go on to talk
about Agile values. So these came from the Agile
Manifesto back in 2001, and a group of
people outlined from largely a technology space, outlined what the core
values were that they found were different about
delivering software. And these became the foundation of various agile methodologies. So I'm going to
talk about Scrum, but there are others
that exist as well. But they've got a common thread in the values and principles that I'm
going to talk about. And the idea behind them is to foster a culture
of collaboration, flexibility, customer
centricity in software development and beyond. Indeed, as Agile has become more popular over the
last couple of decades, it's expanded well
beyond the realms of just managing software
development projects. So the four Agile values to remember are individuals
and interactions, over processes and
tools, working software, over comprehensive
documentation, customer collaboration
over contract negotiation, responding to change
over following a plan. So let's detail each
one of those in turn. So individuals and interactions
over processes and tools. So what this means is adopting
a people centric focus. So it's not just about making sure all of the processes and documents are in place, but if you're ignoring
people and if you're ignoring the dialogue and the communication
required in your project, then that's probably
not a good thing. And so this way of
thinking is about prioritizing the people
first over processes, above and beyond the processes. So then communication
over process, again, it's all well and good
following the process, but have you communicated it. But this often happens in projects where people
say things like, Well, I did write it down over there, but did you tell anyone
about it? Did you ping me? Did you talk to me about it? If you don't communicate, then people aren't going
to understand. They aren't going to be aware. And then cross functional
collaboration. So this specific
way of working puts a focus on not just
staying in your silo, but getting out of your silo and actually building bridges
to other parts of the organization because cross functional collaboration
allows innovation, it allows ideas to, um, to mix, and that's a
good thing in organization. And I've got an example
here from Spotify, which is well documented online. They their organization empowers small autonomous squads for quick decisions and innovation. So the way they set up their
delivery organizations is in very small manageable teams so that people can
be people centric, but they can communicate because as teams grow
larger and larger, then the communication
interactions become infinitely
more complicated. So keeping things small is from a team
delivery perspective, is one way that Spotify is making sure that individuals
shine in their organization. So working software over
comprehensive documentation. So this is kind of similar to the first one in that
it's not people this time, but it's software, or
you could see this as deliverables or
development or build. Like, the actual
tangible product is more important than
the documentation. So it's all well and
good spending loads of time writing down strategies, doing research,
preparing analysis. But what have you
actually built? And that's why in Agile, there's a massive focus on functionality on actually
just getting something out there so it can be validated and you can
start to understand with feedback from your
customers if it's working as they would have hoped or if they're
getting value out of it. So that idea of delivering
value to the customer is super central and is very important
when it comes to agile. And then, with that, because
it works hand in hand, if you want to deliver
value to a customer, but you know, quickly, then it does mean that
you're going to have to have that fast feedback loop
and iterative improvement. So it's not saying that
you're going to just deliver everything in
this short space of time, but you're going to find
ways to chunk the value up appropriately so that you can get fast feedback and
then iterate as you go. So as an example, in this case, start up usually
startup usually release MVPs early and then focus on user feedback so
they can iterate on it. So they don't keep it, you know, locked up in a
cupboard for years and years and
years, tweaking it. Indefinitely. The idea
is to do something, get it out to the market at
ASAP and then get feedback. So that's working software over comprehensive
documentation. The next one is
customer collaboration over contract negotiation. So again, following
in the same theme, we want to be interacting
regularly with our customers, and we don't want to be welding a long contract
over them, saying, Well, this is how it has to be, but we want to have that
continued interaction. One of the challenges
with Agile is that it is difficult to work within
a contract confinement. It does lend itself much more to sort of a time and
materials evolving type of agreements with
your customers. I'm thinking about
if you're, you know, a development organization and you're creating something
with your customer. Often agile works best
in an environment where there is an understanding that there's a lot of unknowns, there's a lot of
assumptions, and therefore, it's difficult to create a watertight contract
that you can deliver to. So if you have a
watertight contract, it's going to be
extremely difficult for you to operate
in an agile way. I suppose that's my
key message there. Because you are integrating
that feedback as you go along and you are
adapting as you go along. Like, if there were all
the knowns outlined upfront and a really clear contract and
statement of work, then there is less of a need
to lean on agile principles because there is so much
known and hence why this was specifically
evolved out of software development
life cycles, which are inherently unknown
and evolving in process. So it's all about that
customer collaboration. But my warning is make sure that the contract actually lends itself to that
way of working. It's not always the case. My example that I chose here
was the NHS COVID 19 app. So it was first released
and quite quickly because, obviously, we had
the global pandemic, and there was a need to get
something to the market ASAP. So it was something that they released and had
issues and had to, you know, embrace that feedback and resolve it as
quickly as possible. And then the last one is responding to change
over following a plan. So in Prince two
project management, we talk a lot about
the project plan, and it is a really
essential document, and Agile is not anti planning. But what Agile is is highly responsive to market
conditions and change, like people change, times change, the environment changes. So it's about embracing that flexibility and not
sticking rigidly to your plan when actually everything
else has changed because that's where
often projects and businesses erode
their benefits, really, because the
landscape changed. And so maybe the reason you
started your project in the first place isn't
as relevant anymore, and therefore, we need to adjust according to that change. And that can also
come in the form of evolving requirements as
things are more known, and it's good to be
adaptable to those changes. And this is often an area in roles people are
really looking for because we live and work in a very ambiguous world
and a very fragile world, which is often often has wild issues that come up
and that can't be predicted. So that's really important from an agile value perspective. The example I've chosen here
is the fact that Amazon rapidly adapt services based on trends driving
ecommerce success. So they've been going,
I think, since, is it the early
2000s or late 1990s? But they obviously
jumped on the bandwagon, like, of selling books online, the.com era, ecommerce,
more broadly, technology trends, cloud
trends, et cetera. So they're a really
good example of an organization that has been very responsive to
change over time.
4. Agile Principles: So the principles, a
little bit more detail. So again, as part of
the Agile manifesto, there was 12 principles
that were broken down, and these provide the foundation for implementing
agile methodologies. These principles
emphasize flexibility, collaboration, and
customer satisfaction. So when people talk about agile. The thing that's really
important to internalize is the values and the principles that I've just spoken about
and I will talk about now. So rather than any one
way of doing things, it's more about a mindset and a philosophy of
delivery and building. That is important to adopt. It's not like you must
do this on a Monday. Like, those rules, those
guidelines and rules, they do exist within Scrum, which is an agile methodology. But really, being agile is actually a mindset and
a way of thinking. So let's step through this.
So satisfying the customer. So they are the
highest priority. If we're not delivering for the customer and we're not
taking their feedback, then what is this all for? So having an extreme
customer focus is at the heart of
it. Welcoming change. So this is counterintuitive to human nature and
our own psychology. Like, we are programmed
to like stability, but Agile just flips
that and requires you to actually be open
and welcoming of change. So that can come in the
form of requirements and, you know, your
environment changing, as I've just outlined. But just catch yourself when you are trying to be
more rigid about how things should be and instead
loosen up and be a bit more open to different
ways of working. Frequent delivery
and a preference for shorter time frames. So as mentioned, if you want to try and get that feedback
from your customer, it's advisable that
you break it down into the smallest constituent
parts that you can and then show that to
your customer ASAP. Working together daily
is another principle. So they believe that this especially working together
between the business and developers just allows there
not to be a disconnect in language and in delivery and
in goals and objectives. So that's a really key part of agile having
an agile mindset. Motivated individuals like hire and promote people who are
intrinsically motivated, put people in the right
roles to start with, and then trust them
to do their job. It's really important.
Like, because this is such a empowering sort of
mindset and framework, if you don't do this among
motivated individuals, then there's a lot of room
for people to take advantage. That's in my own experience. So you really do have to hire the right people and trust
them to do their job. Face to face conversation. So I think it's like a
very high percentage of communication is
actually non verbal. And so face to face, even though we live in
this digital age now, there's so much, you know, benefits using online tools, the absolute preferred mode of operation mode of
communication is face to face, and it always has been. And I can't I can't see a
world where face to face is ever going to be worse than
communicating digitally. So that's the preference.
Working software is the primary
measure of progress. So it's not about
following processes, it's not about writing
documentation. It's about getting results. It's about building stuff. It's about getting that
feedback, showing the customer. So that's the primary
measure of success. And that's kind of
a real step change from the print to methodology or the
waterfall methodology, where if you're
closing those stages and you're closing those tasks, then you can say,
Yeah, that's progress. But actually, what
have you delivered? Sustainable development's
really important. I've got a plant there, but I don't mean in a plant sense. I mean, everyone should feel that they can
maintain this pace. So even though it's called
a sprint, for example, which is part of scrum, we shouldn't all feel
like we're saying bol and we're doing 100 meter
sprint, like, all the time. That's not sustainable. So we want this pace to be consistent, that we can commit to it,
that we can be reliable, with our estimates,
with our team. So we are looking for
that sustainable pace. And technical excellence. So that starts with good design, and it also enhances agility. So if we have good
design upfront or if we iterate the design as we go along and we build
more and we release more, then we know that's going
to enhance our agility, because if we design poorly, it's going to have a negative
consequence down the line. And then we've got simplicity. So we're always seeking the
most simple way forward. We're not building
for the sake of it. It's not code as art or
delivery as some art. There has to be some pragmatism with how we go about things. So we actually want to maximize the things that aren't done. And I'm very bad
at this, actually, but actually saying no to things is a very,
very good option. So keeping things simple is, again, another essential,
agile principle. Then another thing you
might not have heard of before is self organizing teams. So it's a bit of a
different management style, but it kind of lends
itself quite well to the motivated individuals
principle that's above in that if you hire good people and
they are skilled, then in theory, you
just need to give them what the outcome required is or what the problem is
even, not even the solution. And then they should be able to organize themselves to
get the best results. So people who feel responsible
for their work then feel self motivated and then can contribute in the team
in a meaningful way. And then the final one is
reflection and adaption. So it's really
important to reflect on your reflect on your work and also your inputs
to that work. And that ability to reflect then gives you an
opportunity to improve and adapt your ways of working or your approaches
or your outcomes, and it allows you to tune and adjust your behavior regularly. So this is a really
different principle that's not existing in other
types of project management. I mean, there is, you know, lessons learned, documents, and there's closure
reports at the end. But this really regular
opportunity to get that internal introspection is really important for
an agile mindset. So they're the 12
principles that you should definitely
internalize. So in this really brief
module that we've covered, the summary is about prioritizing people
and communication, trying to be flexible and
adaptable as much of the time, obsessing about your customer, and always thinking
about your customer in every action and focusing on simplicity and not trying to do everything and instead deliver
at a sustainable pace, which is enjoyable
and consistent.
5. Scrum Intro: So let's move on to Scrum, which is a different well, it's a framework within
the Agile, you know, that came out of Agile, which is used to
support teams in developing and sustaining
complex projects. So this is a
delivery methodology which comes under
the Agile umbrella. So as part of this overview, I'm going to be taking
you through what the framework is and the various terminologies
that you need to understand. I'm going to be
spelling out what the accountabilities are
that you need to master. I'm going to be sharing what
the artifacts are that you again need to master
and understand. I'm going to be
talking through what the different Scrum events
are and what they look like. And then you will be able
to at the end of this, implement Scrum in
real world scenarios. So that's even in
your personal life or professional life. If there's anything you want to use this delivery
methodology for, then you can take areas of
it that you think would be useful and use
them in your life. And so I think some
of the benefits and outcomes of using Scrum are that it definitely increases
your collaboration, productivity, efficiency. It does bring better
project transparency because it's got a very
standardized approach and it's very data driven. It makes you more adaptable
because adaptability is built into those events that
are held every spring. It should yield higher
quality deliverables because of the flow of the work. And I think your stakeholders will be more satisfied because they'll be able to see
your progress regularly. And it should also make your
team more happy as well, because everyone will
know what to expect, and there'll be a
sustainable workplace. So they're the
objectives and benefits of learning about
Scrum and using Scrum.
6. Scrum Artefacts & Events: This is a really
key framework for Scrum that I come back
to time and time again. And this is what this
is how I'm going to layer the information
that I'm going to share with you throughout the
rest of the presentation. So the Scrum framework is composed of
artifacts and events. Events are sometimes
referred to as ceremonies. So the artifacts are
really like documents, and the events are kind
of usually meetings. And that's what makes up the scrum the workflow
basically as part of Scrum. And these are the items that require regular
inspection and adaption. And this is what makes
the scrum framework so nice because it
just makes everything really known and transparent
and it really allows for continuous improvement
to come through. So the blue here, we've
got the artifacts, and the yellow here,
we've got the events. So we've already talked
about the three key roles as part of the scrum framework. So just to step through, the first artifact is
obviously the product backlog. So without our product backlog, then we don't actually know what the team needs to be delivering. And so that's why
that's the product owner's responsibility
to make sure everything's nicely spelled out at a high level and prioritized. Then we've got a sprint
planning meeting, which is an event. So this is a meeting that
will happen once per sprint, where we start the sprint and we take the product backlog items, and then we break them down. And this is the bit
that the developers are responsible
for traditionally. Sorry, the sprint
backlog is what the developers are responsible
for traditionally. The team is responsible
for making sure that they turn up and discuss
the sprint items. And then we take that sprint as an output of that
sprint planning meeting, we actually end up
with a sprint backlog. So it's a detail of
all the key items that the team commits to
delivering in the next sprint. So then we move
on to the sprint, which is typically one
to four weeks in length. As part of that sprint, we commit to meeting daily
in a daily Scrum meeting. So that's another one of
the events there in yellow. So typically sprints are
like two weeks long. Two weeks or three weeks is the most common length
of time I've seen. Then during that sprint, we'll actually have
another backlog refinement meeting because this meeting will feed the
product backlog meeting. Sorry, this backlog
refinement meeting will discuss the
product backlog. Sorry. And we will talk
about the key items and questions that might
be as a team because then we need to make
sure that we're ready for the next
sprint planning meeting. And the product backlog is the input for the sprint
planning meeting. So every sprint, we make time to discuss the product backlog
and to make sure it's in a good shape so that we've got enough stuff in our
backlog so that we can so that our horizon for the next few sprints is relatively clear in terms of what the team is
going to be doing. And then once we've
finished the sprint, we do a sprint review meeting with all of our key
stakeholders and our customers if required and as required and
as preferred, really. And then, usually quite
quickly after that, we have a retro meeting. So this is about bringing
visibility to the delivery, and then this is about the
inspection and adaptation, the sprint retro meeting. So these are the key artifacts and events that
I'm going to step through bit by bit just so that you've got
a proper understanding, depending on what role
you are in how you're inputting and adding
value to the delivery. So I've just talked
these through really. So all the product backlog is a prioritized list
of project tasks. The sprint planning meeting defines the work for
the coming sprint. The sprint backlog actually is the task selected for
the current sprint. The daily Scrum meeting is the opportunity for the team
to do a daily check in. The backlog refinement
meeting is about refining, estimating and estimating
the future backlog items. The sprint review
meeting is about showcasing completed
work publicly so that you can
get that feedback. And then the Sprint
Retro meeting reviews all the processes and the areas of improvement
so that you can discuss those openly as
a team and move forward. So I am going to
be talking a bit more in depth now about
the product backlog. So what is a product backlog? Well, let's start with the Y. So the idea behind
this is to plan and commit to the work
for the upcoming sprint. So it's actually not just
about the upcoming sprint, but it's also
about, like, beyond the current sprint, as well. But it's just so
that there is a list of work items that
can be discussed. One of the key outputs
of this meeting is the sprint backlog with tasks committed to achieving
the sprint goal. And the inputs to this item,
what did we say this one, the artifact is the refined
product backlog items, insights from previous retro and then team capacity
and velocity. So as part of the
product backlog, we would need to have items that have been
discussed and have got a level of detail on them. We also want to be getting
feedback from the team, and this is also demo as well. So we take feedback
from the customer and internally from the retro, and that also feeds
the product backlog. And then we also are
considering the team's capacity and velocity because
we don't want to, you know, have loads
and loads on there beyond which will ever be
possible for the actual team. I'm thinking, say, for example, if you've got a team
of five and you've got 1,000 items on your backlog, so we need to take that
into consideration. So things that we
would usually do during on this artifact
is prioritize, break down the task where possible and give
high level estimates. And generally for
the product backlog, we try and keep the meeting
focused and time limited. We try and make sure that
everything's assigned properly, that we improve collaboration, and we always as usual, be prepared to adapt our plans. So that is the product backlog. It's a prioritized list of features, enhancements,
and fixes. So I've given an example here, and again, this has got
a little pencil there. So this is an editable slide. There are many tools for
detailing a product backlog, like Jira as an example. This is just a template
I've used on Google Sheets. There are lots of different
types of work items. We a backlog, generally. You've got epics,
you've got features, you've got user
stories, you've got bugs, and then you've got tasks. I've put an example of each here just so that
you can understand. Epic is something that
quite often we'll take, you know, a few
sprints to complete, so it's a larger piece of work. Features typically
are components that can be easily represented
as a feature. So, for example,
a particular part of a UI could be a feature. A user story is a requirement
that comes from the user, and it's written in
a particular format that I'll talk
about in a second. Bugs are, you know, issues that are
found in the system, and tasks are they could
be technical tasks. They could be
documentation tasks. There are things that
the project need to do that aren't typically
associated with the user. Or the user might be
the end beneficiary, but it's more of a more
of a back end task. It's not driven by
a user requirement, but it's as a result of a
user requirement, usually. So I've got so let's talk about the
user story in particular because this is an area
that's important to understand because it's got
quite a specific format. So it's typically
written like this. As a user of some description, I want to do something so
that for a particular reason. So as this example here, as a SOS representative, I want to quickly update customer profiles so that I can save time
during follow up. So it's usually
written in this way, so it spells out really clearly who is giving
the requirement, what they actually want,
and then why they want it. So this is the standard
format of a user story. There's a lot more detail and
information on this online. And then acceptance criteria. Again, this is a particular
format that's quite popular. It's called the given
when then format. So this just spells
out and there's often many acceptance criteria as part of a particular user story. What is the definition of success for completing
this user story? So here's an example. Given
I am on a customer profile, when I click the
quick Update button, then I can edit the key
contact information and save changes
within 30 seconds. So you can see here that I'm
spelling out what the sort of preconditions and
conditions are for the user, that would mean, like,
a particular part of this user story is
deemed a success. So that's one area that is definitely worth
knowing about and just understanding
that an epic is a larger sort of
umbrella of work, and a feature is a particular component
that you can break down. And then often
user stories would be attached to either
features or epics, and tasks can also be attached to user stories,
features and epics. And indeed, so can bugs, as well as and when they're raised as a result of testing. Another thing, a key area
of the product backlog, I want to mention
is the priority. So this is obviously, as
always, really important. I've got a red amber green here to indicate high,
medium and low. This can also be a
sequential priority like one, two,
three, four, five, but it's really
important that there is some sort of ordering given
on the product backlog, otherwise, people won't know what's most important for
the user to focus on next. I've also given
an estimate here. So this is a popular estimation
mechanism called Fibonacci, whereby they take a a
mathematical sequence that exists within nature and use it as the mechanism for
giving relative estimates. So the idea here
because we live in, you know, we're in
this agile world, and there's a lot of uncertainty is that we don't directly associate an estimate
with a sizing, but instead, we give
it a relative sizing. So we're not saying
this will take exactly three days,
we're saying, Okay, streamlining customer service
interaction processes 13 is bigger than enhancing the data entry interface because
that's the two. So, relatively speaking, 13
is much bigger than two, and so we believe this piece of work is much
bigger than this one. So that's all that
the estimate here, which is in Fibonacci using the Fibonacci sequence
is actually trying to give us is just a
relative estimate. And then as your team gets more more mature and becomes
more self organizing, then they'll really start to understand what sizing
means for them. So it's quite nice when you
get to that point where people almost can start giving a timelines quite accurately because they've got so good at sizing, relatively speaking. So that's a real
sign of maturity in your delivery team
from a scrum perspective. And then, of course,
you've then got the owner. So like, who is responsible
for the actual epic feature, user story, bug, and task. So all I'm doing here
is showing you sort of what the makeup
of a product backlog looks like and some of the
key components for success. So now we're on to the
sprint planning meeting. So why do we do the
sprint planning meeting? It's to plan and commit to the work for the
upcoming sprint. And again, the whole team
is part of this meeting. The output of this sprint
is the sprint backlog. So that's so that we've
got a detailed list of the tasks that are needed
to achieve the sprint goal. And the input is obviously all of the refined
product backlog items, insights from previous retro, the team capacity and velocity. So all the things that
we spoke about for the product backlog
are also inputs here. And then popular methods here is to make sure that you can
prioritize the tasks again, break them down further, do even more detailed estimation based on your more
detailed understanding. And tips for success
in this meeting is it's typically one
to 3 hours in length. I always think planning is
such a worthwhile activity. Like, it really yields, great
benefits within delivery, because the more time
you spend planning, the more likely you
are to, you know, have a successful
outcome and really get that clear ownership
so that people know what they are and
are not responsible for. And it just allows people to collaborate and
fosters communication and make sure there's that
alignment within the team, which is super important. So that's the sprint
planning meeting. Now we move on to
the sprint backlog, which is just the lower level of detail down on the
product backlog. So this is fundamentally a
list of tasks for the sprint. And the reason we do it is
to make sure that there's an organized task list that's associated with
the overall sprint goal. Again, it's the team that are partly responsible
for this artifact. And we want to at the end of it, have a detailed
list of tasks that contribute to achieving
the sprint goal. And the inputs to it are the refined product
backlog items. So now everything should
be nicely refined. The estimation of effort. So things should be estimated. So we understand before we start the sprint, like
what we're taking on. Is it too much? Can
we commit to it? And then insights from the
sprint planning session. So that should have all
informed the sprint backlog. And a lot of the popular
methods here are to have task breakdown
sessions to decompose the product backlog to make sure that developers or people doing the work are really understanding what the
build steps would be, that we do the estimation, and that we assign the task based on people's skills
and availability. So some of the tips for success
with the sprint backlog, and there's tooling
that helps with this, but just to make sure
everything's transparent. So that's why tooling
is often used, make it accessible to all so that you can
visualize the delivery. And then also make sure that
you've got a sprint goal that's based on the selected
items for your sprint. So if you're able to
summarize that in a nice way, that's a great
communication tool. And here's an example
of sprint backlog, and hopefully this shows you how this is different
from the product backlog. So I've got the
sprint goal here, update customer
profiles quickly for efficient follow ups and log detailed interactions for
personalized support. So I've not listed out just
all of the user stories, tasks, and bugs
that we're fixing. I've tried to wrap
it up into, like, a high level objective
for the sprint, just so that it's a
communication tool. But what you would typically do then in the sprint backlog, why it's different from
the product backlog, is if you, for example, got your user stories here, so I've got some
example examples, what you would
then do as part of your sprint planning
meeting is actually start breaking down
those tasks exactly, so that you know really
clearly what needs to be done. And then you would even
estimate these items as well. And then you would also break down the ownership
of those tasks. So the product backlog
is the highest level, it's the most undefined. Then you would try
and refine bits of that product backlog that
need to be done ASAP. You would take that
more refined version. You would bring it into the
sprint planning meeting. You would then aim to get a breakdown of the
tasks required and ownership and sizing to then make sure that when
you start your sprint, you've got everything that
you need to be successful. So the daily Scrum meeting
is what it says on the tin. It's a meeting that's usually
15 minutes happens daily. And it's about figuring out
what has to be done today, but also a discussion about if there's any blockers
or impediments or if you need help
with anything, it's just your opportunity
to communicate, really. So it's that space
where, you know, if you've got a question or
an issue, you can raise it. And it allows us to stay on track because if
after several days, the scrum master notices, we're not talking about a
whole swath of our backlog, then we know that we're going to be going
off track somewhat. So that's really useful. So there's lots of
popular methods here. You can have quite a
standard way of doing it, a very formulaic
approach to doing it. You can walk the board, which is the Cam Ban board, which visualizes
the delivery tasks in the various stages. Some key questions that you
can get people to answer. What did I accomplish? What's my goal for today?
What's slowing me down? Um, you can have
a focus question. And then tips for
success are trying to stay within the
time box, really. People do like to go off track, but that's an
indication that you need to have separate conversations
between particular people, and there's not enough alignment happening outside of
the daily stand up. And yeah, so just for
identifying issues, blocking off enough
time to identify those issues outside
of the scrum meeting. It's often the case that authority figures
in these meetings can be counterproductive
because you really want the team to
be as open as possible. And the scrum master, even though they're
responsible for the artifacts and the events, they shouldn't really
be meddling too much in the task board because that's the teams teams
artifact to share, you know, their value and their delivery
progress, basically. So while we're in the sprint, we will be doing a backlog
refinement meeting because we need to get
our product backlog in a good shape for our next horizon so that
we can then complete, you know, the sprint
again, that cycle again. So the purpose of the
backlog refinement meeting is to clarify and estimate upcoming backlog items so that they are ready for sprint planning, as just mentioned. We want to have a
reasonably well defined, well understood
product backlog that are ready for the inclusion
in the future sprints. So that's what we're hoping to get out of the
backlog refinement. What often happens in practice is we just have a load
of questions that the product owner generally
needs to go and find out from the customer or needs to
research or give answers to. And that's often what happens. And then the input is unrefined
product backlog items, insights from stakeholders and previous sprint performance
and lessons learned. So say, for example, things came up that we got feedback on, all those items would go
on the backlog and we would discuss them and how we were going
to approach them. Popular methods here for the backlog refinement
meeting are just to discuss and
clarify the backlog items, give estimations
at a high level, and then prioritize based on both business value
and dependencies, because obviously, the there's often tasks that are required
to meet the business value. So it's not always just a case of doing what the
business wants. Like, for example, then you can build up a lot of
technical debt, which won't be good for
the project long term. And like all of the meetings, it's good to time
box them and make sure that things are as
documented as possible. And that obviously depends
on the tooling that you decide to use to
manage your delivery. So now we head into the
sprint review meeting, which is really the culmination of all this hard work
over the sprint. So the reason that we
do this is to demo the work to the relevant stakeholders
and gather the feedback, which is the critical
component of Agile about the customer. The whole team are
usually involved, but other relevant stakeholders, this is their opportunity to
see what the team is up to, and we would typically demo
the completed sprint and give a status update of where we are with the delivery and also
what's on our agenda next. And generally, the
input would be, obviously the completed
work, which we want to show, if possible, and the
stakeholder feedback that we might have had along
the way if we've been, you know, communicating daily. And then any insights
from the product owner or the team about the delivery or about the product
backlog itself. And generally, what would happen is there would
be a demonstration of the completed functionality, and then you would review
some of the metrics, like, for example,
the burn down. That's a whole reporting is actually a whole other
topic of conversation, and the sprint burn
down just shows how many if you're using story points as your
estimation method, how many story points you've delivered in the period of time. And it will show a day
by day burndown to zero. Of you completing the work items that you've had in your
sprint, basically. And there's lots of other
visual reports that really show how productive and
effective your team and consistently
performing your team is. So they're often shown as well. And again, it's good to
time box these activities, and it's really good
to ask questions, and it's this opportunity
to get feedback. So making it as
engaging as possible, as open as possible is really, really good because it's
going to inform your retro. So before we go on to that, I'm just giving you an
example of the kind of information as input you could give to a sprint
review meeting. So generally, you would
recap on what your goal was. You would give a summary of what the key items were that
were in your sprint. You would give a status for whether they were
complete or not, and then you would
give an indication of the sizing and whether you're
going to demo them or not. So here's also an example, as I mentioned, of a burn down. So in this particular sprint, they planned for their
target was around, I don't know, that's about 36. So that's their
sort of happy path down to zero on the burn down. So they were
slightly above that, but this is actually not bad This is actually not
a bad line at all. So what this is
showing that they delivered relatively consistently
all the way through, so that gives me an
indication that they've broken the work down nicely,
they've understood it. And they've been, you know, quite accurate with their
estimation and consistent. But there is a delta here. So they have either
not got some work done or they've moved some stuff
out until the next sprint. So they haven't completely
burned it down to zero. So there is still
something going on here. But this is why it's called
data driven delivery because all of these different visuals and the way that these graphs look, they all have like
reasons behind it that are very
well established. So, for example, if you
have an actual burndown, and this happens very
typically in delivery, that's a straight line, and then it drops down
right at the end, then you can see that
the team's not really estimated and broken down their work properly because they don't know
what they're doing. They don't know what they're
doing. They're doing. Oh, no, it's the demo. We need to get some stuff done. So the reporting is really interesting from
a scrum perspective. And then finally,
the sprint retro that we've been leading up to. So what is the sprint retro
or why do you do it first. So it's really
about reflecting on the previous sprint
and identifying improvements for
the next sprint. So the whole team are
typically involved. And I generally have this raw whereby I say, if
you don't come, then you've literally
got no right to complain because you
don't want people complaining all the
way through and they're not contributing in the retro because that's just annoying from a scrum
master perspective. And what you want to do is get actionable insights to improve the team's performance
and really give responsibility and ownership on that team to make things better, really, because it's, you know, everyone's responsibility. And what I like to do, as well, during the retro is talk about the actions from the
previous retro so that we make sure that we've got that accountability loop. Because if you
don't do that, then we're just documenting
improvements, we never actually
taking any action. So that's kind of a key message, and it's really important. But as input, it would
be obviously the sprint. The sprint is
basically the input. And then it would be the
feedback from team members. So typically, we would
write these on a board. It depends what
tool you're using. And then people would
give their ideas for enhancing their
effectiveness or just, you know, verbalizing
their complaints. And popular methods
of doing this, one of my favorites, actually, is just start,
stop, and continue. So you just have a
number of columns, and then you get people to say what they want
to start doing, what they want to
stop doing, and what they want to
continue doing. And there's lots
of methods online. For how to run a stand up. And you can be almost as
creative as possible, really, and try and mix them up so that they're not getting
stale all the time. Obviously, you can get into, like, tens and 20s
and loads of sprints. And so once you've done it ten, 15, 20 times, like, you're probably going to
want to start mixing it up a little bit so that it's a bit more interesting
and engaging. Yeah, so I've already mentioned this one. I think
this is the key thing. Make sure that you are following and tracking the actions. And here's an example.
It's an editable example, so you can even use
this as a template. So this is the start, stop, continue retro method that, you know, I think is a tried
and tested one, really. So here you just
get people to put their stickers on here with what they want to start,
stop, and continue doing. And then, usually you give
people a few minutes, and then you discuss it. You walk the board,
and you discuss it, or you can just have
discussion freely, and the scrum master
can just type it up. It just depends what
the team wants. Sometimes people put music
on, make it relaxing, but it can be quite a
cathartic meeting, actually. It's a really
important one to have. Even if you just
put 30 minutes in, it's a good forum to have.
7. Scrum Module Summary: So as we draw to a close here, Scrum is based on an empirical
process control theory. It's iterative and
it's incremental. It increases transparency and it allows for inspection
and adaption. So they're also known as
the three pillars of Scrum, transparency, inspection, and adaption. That's
what it's all about. It puts collaboration and
communication at the heart. It is an agile methodology. I wants you to do regular retrospective so the team can improve
continuously. And the primary goal
of it is to deliver value that meets
the stakeholders' needs and expectations. So hopefully, you can see why
SCRUM is an agile method, as well as delivering
methodology in its own right
because it's really living all of those
values and principles.
Anna Bromley
