Hi and welcome to Scrum by the Book As Agile ways of working continue to grow
within organizations, many leaders understand the benefits of working with Agile methodologies,
such as Scrum, - but sometimes these leaders don't understand
how they work. This video is a detailed explanation of Scrum
by the Book. I have made it to give anyone who have heard
of Scrum but doesn't really know what it is - a way of broaden their horizon. This detailed explanation consists of an initial
quick overview followed by an in depth look at all the details. If you - after watching this - is in need
for only the brief overview - please watch my shorter video - named on Scrum by the book
- an overview. There is a link at the end of the video to
my youtube channel - where it can be found. I'm Per Beining. I work as an Agile Transformation Coach and
is involved with Agile and Scrum Trainer. Please get back to me - either in the comments,
by email or by twitter - should you have suggestions for how I could improve my world view or interpretation
of Scrum by the Book. Please enjoy... Scrum Is an Iterative incremental approach
for delivering complex products The Iterative part consists of the main iteration
- which in scrum is called a Sprint - It's time boxed and has a duration of 1 month or
less. Another iterative part is on a daily basis
- which in many drawings of the Scrum Process is placed here at the top. Lets start out with looking at the 4 Components
- that Scrum consists of Roles - Which I will draw as small stickmen
and stick women - with their name below There is Events - Which I will draw as a cloud
and label them inside. Some refer to these as Ceremonies - and in
a traditional approach they would probably be called Meetings. Then theres Artifacts - which is all the stuff
that is used and produced during a sprint. These are drawn like small illustration with
their name below. And finally there is Rules - which binds the
Roles, the Events and the Artifacts together. The rules is not drawn explicitly - but is
covered by my explanations. Lets start out by taking a brief look a the
3 roles. After walking through the end-to-end process
we will take a more detailed look at each of the Roles, each of the Events and each
of the Artifacts and their characteristics. Lets start out with the end-2-end overview
of the process. The first role is the Development team. The development team are the ones actually
delivering the incremental changes for our product. The second role is the Scrum Master. He or in this case: She - is responsible for
the Scrum Process. The third role is the Product Owner. This role is the owner of the Requirements
that needs to be developed and implemented by the Development team. Lets move on to the Artifacts and the Events. In Scrum the Requirements catalogue is called
a Product Backlog. This is one of the most important Artifacts
in Scrum. I've drawn it like a Funnel - quite heavily
inspired by Henrik Kniberg Presentation on Product Ownership in a nutshell - which is
an absolutely must see video (I’ve put a link at the end of the presentation). The Product Backlog is an ordered list of
all know requirements - Which in Scrum are called Product Backlog Items (sometimes they
are abbreviated PBIs) the Product Backlog is visible to anyone. And like a funnel - theres a fixed amount
of stuff that can come through - So prioritization is really important as well as the quality
of the descriptions of each of the Product Backlog Items. Moving on the the next artifact:
When a Sprint is completed - the outcome will always be a Potentially Shippable Product
Increment. Whether to release the new functionality or
not is entirely up to the Product Owner to decide. But the outcome of the sprint - must be an
increment of suitable quality that makes it possible to Release. So how do the Development Team, The Scrum
Master and the Product Owner - all 3 together also referred to as the Scrum Team - move
from the ordered list of Items found in the Product Backlog to a Potentially Releasable
Product Increment? The Initial step is the Event called: Sprint
Planning - this is where we plan the work to be performed in the Sprint. The outcome of the Sprint Planning is a Sprint
Backlog. The sprint Backlog consists of the top prioritized
Product Backlog Items that can fit into the sprint - as well as a plan for delivering
them. Another outcome is the Sprint Goal, which
is an objective that will be met within the sprint
through the implementation of the selected Product Backlog Items
The Sprint Goal is used for guidance to the team during the build of the increment. Another outcome of the Sprint Planning is
a breakdown of Product Backlog Items into Tasks. When The Sprint Planning has ended - the Sprint
Backlog is defined, a Sprint Goal is Set and The Sprint Backlog Items has been decomposed
into Tasks of 1 day or less duration, well then it's time for the Sprint to start. During the sprint - there is a Daily event. This daily event is called the Daily Scrum
- and is a 15 min time boxed event where the development team synchronizes all of their
activities and make a plan for the next 24 hours. As mentioned earlier - this event in many
drawings of the Scrum model is placed at the top of the sprint iteration. I do though prefer to put it inside the main
sprint iteration - so - lets move it…. Reason for this move is that During the Daily
Scrum all of the Artifacts from the Sprint planning are being considered - so i like
to have them next to each other in the picture. The Development Team uses the Daily Scrum
to inspect progress towards the Sprint Goal and to inspect how progress is trending towards
the work in the Sprint Backlog. Are we still on track and will we actually
be able to deliver as promised. A tool used for the measuring of the progress
could be a Burndown or a Burnup Chart. The Burndown chart gives an overview of how
much work remains until the end of Sprint compared to how much capacity we have left
to do the work. As mentioned earlier - When a Sprint is completed
- the outcome will be a Potentially Releasable Product Increment. When a Product Backlog Item or an Increment
is described as Done - everyone must have the same understanding of what Done means. This Shared understanding is know as “Definition
of Done”. When the Sprint has Ended - the produced increment
is reviewed. This event is called a Sprint Review. It's an informal meeting with the intend to
elicit feedback and foster collaboration. As the last Event in the Sprint - the Sprint
Retrospective is held. This Event offers an opportunity for the Development
Team, The Product Owner and The Scrum Master to inspect themselves and create a plan for
improvements to be enacted on during the next sprint. And then it's time for the next Sprint. And thats starts - year you guessed right
- with a Sprint Planning and then everything repeats itself again. During the Sprint another Event is taking
place - This event is called the Product Backlog Grooming - or Product Backlog Refinement. The objective here is to Add details to existing
Product Backlog Items, Estimate the complexity of these and Prioritize them. So the Product Backlog at all times is fit
and in a healthy shape. One final Event is the Sprint Cancellation. This is not something that happens often,
but sometimes the Sprint Goal becomes obsolete and the Product Owner can then decide to cancel
the entire sprint and go back and start a new Sprint Planning. Finally I've drawn a couple of additional
Roles into the picture. These are not Officially Roles in the Scrum
framework - and are most certainly not part of the Scrum team - they are outside - but
I’ve included them just to give a complete overview. It's the Other Stakeholders and the organization. We will in the upcoming detailing of the Roles,
Events and Artifacts and the rules binding these together - touch on these 2 unofficial
Roles. One last important notice - during this overview
- is that sometimes in Scrum theory we make reference to something called The Scrum Team. The Scrum Team consists of all the 3 official
roles: The development Team, The Scrum Master and the Product Owner. After this walk through of the end-to-end
overview of the different Roles, Events and Artifcats in Scrum - and how they are related
- lets move all the way back to where we started - and step into the different details of each
of the different components: Lets start out with the development team. The development team in Scrum, has a size
of minimum 3 people - going up to a maximum of 9 - not counting the Scrum Master and the
Product Owner. Should the person acting in the role of Scrum
Master or in the role of The Product Owner be participating in the actual creation of
the Product increment - then that person also fills a role as a developer - and must be
counted as part of the Development Team. A key characteristic of the development Team
is that they are self organizing as a team. So no one steps in and tells them what to
do. As part of this self-organisation they also
jointly figure out who is performing what work to reach the Sprint Goal. It's important to notice that it's only the
Development Team members that can decide on how to turn Product Backlog Items into potentially
releasable functionality. Not even the Scrum Master has influence on
this. This is done to optimize the development teams
overall Efficiency & Effectiveness. Efficiency is that things are done in the
right order. And Effectiveness is that we do the right
things. A lot of effort normally goes into optimizing
the teams Productivity - which rephrased would be to do as much work as possible. It's typically a lot easier to boost the Value
and Benefits created for the Business by the Development team - by looking at Efficiency
and Effectiveness. In Scrum The Development Team must be cross
functional - so they as a team - without external help are able to create a Product increment. The Development Team in Scrum is also jointly
accountable for the work being done. It's not a Project Manager (a role that you
will observe not event exists in Scrum) or the Product Owner or the Scrum Master - but
it’s the team themselves - that are accountable. This to many teams will reveal itself as one
of the biggest differences from the way they have been working before taking on Scrum. As the Product Owner is the one Responsible
for the Requirements - it's obvious that the Development Team only solves work coming from
the Product Owner. Obvious in theory at least. But as many teams historically has been given
work from a lot of different people in the organisation - Changing this pattern of saying
YES! to work not coming from the Product owner can be hard. But it is a must to get Scrum to work. Daily Scrum is often referred to as The heart
of Scrum. This daily reoccurring event - is conducted
by the Development Team. It's important to emphasize that this is the
Development Teams meeting - with the purpose to ensure that we as a team are on right track
and will be able to accomplish the Sprint Goal within the boundaries of the current
Sprint. The Scrum Master - as the one responsible
for the Scrum Process - will make arrangements so everyone knows when and where Daily Scrum
is happening: Which is same time and same place every day. But should the Scrum Master not be present
- the Daily Scrum will started on time - by the team them self. The only title for a person on the Development
team is "Developer". This is regardless of particular domains of
the work that needs to be addressed - like Business Analysis or Testing. And in Scrum by the Book - there are no exception
to this rule. This also means that there are no sub-teams. The Estimates for the Ordered Requirements
found in the Product Backlog are given by the Development Team. These estimates are amongst many other purposes
- used by the Product owner to prioritize what order the requirements should be developed
in - with a look at the benefit that they will give and at what cost. One of the outcomes of the Sprint Planning
- is as mentioned in the overview: The Sprint Backlog. The Sprint Backlog is owned by the Development
Team. Which of course falls greatly in line with
the Accountability and self-organisation of the Development team. The creation of the Sprint Backlog is done
collaboratively by the Team. It could be facilitated by the Scrum Master
- if the Development Team requests this. And Supported by the Product Owner - in regards
to details and conversations about the detailed content of the different requirements. But the Sprint Backlog is created as a collaboration
between the members of the Development Team. After the creation of the Sprint Goal - the
Development Team explains to the Product Owner and the Scrum Master how they expect to accomplish
this within the upcoming Sprint. The Development Team Tracks what the remaining
work for the sprint is on a daily basis. This is giving the team insight into whether
or not it likely that they will accomplish the Sprint Goal. This tracking could typically be done in a
Burndown chart. And that’s the development team. The Scrum masters responsibilities is split
into two main areas: First one is as the owner of the Scrum process. This could be seen as a practical pair of
hands making things happen. The other area is ensuring Scrum is understood
and enacted both on the Scrum Team as well as throughout the Organisation. This is in more general Agile approaches referred
to as the Role of The Agile Coach. As Scrum doesn't have such a role - this coaching
part is the responsibility of the Scrum Master. The scrum master helps facilitate the different
Scrum Events. He or she help the participants to understand
the purpose of the Events and also ensures that they are kept within the timeframe. It's important to notice that it is facilitation
thats the key here. And a key characteristic of a great Scrum
Master is good facilitation skills. Luckily facilitation is a skill set that quite
easily can be learned. As part of the facilitation of Scrum Events
- The Scrum Master must ensure that the Daily Scrum is held. The Scrum master does not necessarily need
to be present at the Daily Scrum. But She makes sure that it's held. One characteristic of this event is that it's
held at the same time and same place Every day - this is done to reduce complexity in
the participants calendars. As mentioned earlier when looking at the Development
team - they are Self organizing and Cross-functional. The scrum Master is helping and coaching the
Development team in achieving this. Impediments - in what ever form and number
they appear - are in most projects what could make or break it's success. And off course how they are dealt with. The Scrum master is helping the Development
team with removal of impediments. If the impediment - is outside - what the
Scrum Master can remove on her own - then it's her facilitation skills that comes into
play again. Involving and engaging the people that can
remove the impediment - are a couple of the techniques that can be used. As mentioned in the Overview - the Product
Backlog is a key Artifact. It holds all the requirements - these are
also known as Product Backlog Items. The Scrum Master is helping the Products Owner
in managing the Product Backlog. Part of this is helping the rest of the Scrum
Team - to understand that clear and concise Product
Back Items are important. As paraphrased from Alice’s encounter with
the Cheshire Cat in Wonderlands one could say “If you don't know where you are going,
any road will get you there.” So if you as a Product Owner is not clear
on what you want - and you as a Development Team don't understand it either - end result
could be anything. And often is. Coming from traditional approaches of project
Management - a lot of different people - with all kinds of different agendas - and often
self invented needs - interacts - Directly with the Development
Team - Telling them what they should and must do. Thats not ok! The Scrum master guides these people in understanding
what interactions are helpful and which are not - in other word: when to stay away. When introducing Scrum to an organization
- changing this type of behaviour - can be quite a hassle. But always worth the effort. The Scrum Master helps everyone to understand
that with Scrum - we are working on a new set of rules and a new process with the purpose
of maximizing the Value created by the Scrum Team. Sometimes this is also referred to as "Protecting
the Team" from outside interference. Event though this paraphrasing is correct
- I personally don't like the underlying "Us” versus "Them" The effective Scrum Master instead educates
the outside organization into understanding that the Focal Point for any work is the Product
Owner. And guides them to consult him
- both to understand the Product Vision - and to get transparency into when they could
expect their requirement fulfilled …or denied if thats the case. As mentioned earlier - the second area of
the Scrum Master’s responsibilities is ensuring Scrum is understood and enacted both on the
Scrum Team as well as throughout the Organization. Part of this - is leading and coaching the
Organization in it's Scrum Adaptation. And creating a Plan for how Scrum is implemented
throughout the Organization. Processes can be classified as either Defined
or as Empirical. A Defined process is determined by - having
a well-defined set of inputs - that will results in the same output being generated every time
Empirical Processes are build upon observing, experience or experimenting
They are typically handling something complex and not very well understood. The Scrum Framework is founded on Empirical
Process control theory. The three pillars on which Scrum as an Empirical
Process Control - is founded - are: Transparency, Inspection and Adaptation. 3 Elements most of the Scrum Events embed. Transparency - is that everything is visible
to anyone that has an interest. Nothing is hidden. Inspection - is the effort to constantly verify
that we are on Track. Adaptation - is the constant focus and change
- on how we can do things better. Part of the Scrum Masters responsibilities
is to help employees and stakeholders to enact this Empirical approach to product development. The Scrum Master is a practical pair of hands
towards the process. She causes things to change - with the purpose
of helping the team increase it's productivity. In bigger organizations - with more than one
Scrum Team - the Scrum Master works together with other
Scrum Masters to increase the effectiveness of Scrum in the organization. Lets take a deeper look at the third role:
the Product Owner. He is the owner of the Requirements that needs
to be developed and implemented by the Development team. The Product owner must know - and communicate
- what our Goals and Mission for the product is. This is sometimes in more general Agile terms
referred to as the Product Vision. Clear Knowledge of our Goals and mission - is
a very powerful tool for the Product Owner to prioritize the different requirements and
their order ind the Product Backlog. This knowledge is also enabling the Product
Owner to reject a specific request for new functionality - that falls outside the goal
and mission. Outside the Product Vision one could say. And even though its never funny to be told
"NO - YOU CANT HAVE THAT!" - it enables the one requesting the functionality to get on
with their life - instead of waiting indefinitely for functionality that is so low prioritized
that it will never be delivered. The three pillars on which Scrum as an Empirical
process control is founded are as earlier mentioned Transparency, Inspection and Adaptation. The Transparency of Scrum is clearly present
in the form of the Product Backlog - where all the requirements reside. The Product Owner is responsible for managing
the Product Backlog and it's content: each chunk of requirements is called a Product
Backlog Item. Beside ensuring that the Product Backlog Items
are clearly expressed - it's also the Product owners responsibility to ensure that the Development
Team understands them. This understanding needs to be at a level
that is detailed enough for the Development Team to implement the changes that is requested. The Product Owner is allowed to delegate the
work with the Product Backlog to the Development team or the Scrum Master. But He will ALWAYS remain Accountable for
the Product Backlog and it's content. A central role of the Product owner is also
to talk with other stakeholders. This could be related to discussions about
upcoming functionality based on requests for included new requirements
in the Product Backlog. When a sprint has ended it's entirely up to
the Product Owner to decide if the Product Increment should be released. Another responsibility of the Product Owner
is to Track the overall work remaining for the project. This is at least done at the end of each sprint
- at the Scrum Event called Sprint Review. This status of where the project is - from
an overall point of view - is off course communicated to the Scrum team as well as all other Stakeholders
and the rest of the organization. As mentioned when we looked at the overview
- I have drawn a couple of additional Roles into the picture. These are not Official Roles in Scrum framework
- and are certainly not part of the Scrum team - they are outside. I have though included them to give a complete
overview. It's the Other Stakeholders and the Organization. As indicated earlier - the Development team
is shielded from unwanted interference from outside the Scrum Team. This outside interference - could come from
Other Stakeholders. But in an ideal Scrum World these Other Stakeholder
would respect the rules and talk only to the Product Owner. In an ideal Scrum World - when approached
by Other Stakeholder - The Scrum Master and the Development Team - will always - kindly
but firm - reject requests from Other Stakeholder and ask them to discuss it with the Product
Owner. The Organization - is another of these two
unofficial and outside roles. Again living in an Ideal Scrum World:
The Organisation respects the Product Owners Decisions. Another prerequisite in the ideal Scrum World
is that the Organization is structuring and empowering the Development Teams to be self
organizing and self-managing their work. And that's all there is - at least when talking
about the Roles of Scrum. Lets move on - and take a look at the details
behind the Events Paraphrased one could say that Events are
the pre-scheduled meeting points for everyone on the Scrum Team. In Scrum - predefined Events - are important
to have and uphold to be able to - create regularity
- Minimizes meetings Events are always time boxed - with a maximum
duration - and a clear purpose - to avoid waste of time And when looking at the 3 pillars of Scrum:
- The Events Offers great opportunity to 1. Inspect and 2. Adapt and 3. Give Transparency
- It's often most obvious - In the case that Events are omitted - the result is immediately
reduced Transparency Lets take a look at the Main iteration - in
Scrum as you probably recall - this is called a Sprint. The Sprint is a container for all other Events One of the goals in choosing Sprint Length
- whether it should be 2 weeks or 1 month - is to kept it as small as possible. This is in order to
- keep cost of failure low - keep complexity low
- Decrease risk - avoid changes to the planned work - The
shorter a period we plan work for - the lower the risk of being forced to change what we
have planned - And it gives Predictability Depending on the Domain though - sometimes
it's not possible to deliver anything of value within the chosen sprint length. This could be an indication that the sprint
length is to short. During the duration of a sprint - scope may
be clarified and renegotiated with the Product Owner. As The Development Team work through the Sprint
Backlog - they get smarter - hence good reason to discuss the solution with the Product owner
to ensure as much Value is created as possible. Important though - is that no changes are
made - that would endanger the Sprint Goal And another important focus - is that Quality
Goals - do no decrease Throughout the Sprint - the Development team
is tracking the Work Remaining in the Sprint Backlog The Sprint is a time box - and has a duration
of Maximum 1 month. As you probably recall from the Overview
- there is an Event - where the planning of what is going to be created during the Sprint
- This event is called a Sprint Planning Input for the Sprint planning - are several
Artifacts: - It's the Latest Product increment
- the Development team needs this to extend with more functionality
- It's How many development days we have available during a Sprint
- or in other words: the Projected Capacity of the Development Team - Knowledge about Past Performance - is also
necessary - to be able to estimate what is possible to Achieve during the upcoming sprint
- with the projected capacity we have. - The Definition of Done - is also used as
input. If it's not clear to everyone when Product
Backlog Items or the Product increment is Done - how can we know when to stop working
on it. It's used to help the Development team decompose
all tasks needed to deliver the Requirements. - And finally - the Product Backlog
- where the ordered Product Backlog Items are taken from. The Sprint Planning Event is as most Scrum
Events an opportunity to Inspect and Adapt. Outcome from the Sprint planning is
- A Clear picture - for the Whole Scrum Team - of what can be achieved
- And how the Development Team has planned to do the chosen work Artifacts supporting this is the Sprint Backlog. The Sprint Backlog consists of the selected
Product Backlog Items from the Product Backlog and a plan for how it will be achieved. Also the Sprint Goal is part of the Artifacts
being delivered. The Product Backlog Items is Broken down into
manageable chunks - called Tasks. The Sprint Planning is as all Scrum Events
a time box. It has a duration of Maximum 8 hours for a
1 month sprint. For shorter sprints it's probably not that
much. On a daily basis - the Team meats up for one
of the most important Scrum Events: - when it comes to Inspection and Adaptation…. This meeting is the Daily Scrum Outcomes of the Sprint Planning are the Sprint
Backlog and the Sprint Goal. The first one - the Sprint Backlog - contains
- as mentioned a few times earlier - the highest prioritized Product Backlog Items and a Plan
for delivering them It's content is Self-organized by the Team
And the Product Backlog Items are Decomposed into Tasks of 1 day or less The Second outcome - the Sprint Goal - is
a definition of what to build during the Sprint. The purpose of the Sprint Goal - is to cause
the Team to Work together - Rather than on separate initiatives. The Goal of the Daily Scrum is to optimize
the probability for the Team to reach it's Sprint Goal. The Inspection part - is done through inspection
of progress and trends towards achieving the Sprint Goal. And if the Trend shows that the team cannot
achieve the Goal - Adaptation is needed. The benefits of the Daily Scrum is that
- it Improves communication - it Eliminates other meetings
- it Identifies impediments - it Promotes quick decision making
- and it Improves the Development teams knowledge Beside those benefits - it's a Mechanism to
help improve self organization of the Development Team The daily Scrum is held at the Same time - same
place - with the same agenda - every day. The Agenda for every team member is to answer
the question of "How will I help the team meet our sprint
goal" This is done by answering 3 questions: Since
Last, Until Next time and Impediments / Help - Since Last I have brought us closer to the
goal by doing "this" - Until next time I will bring us closer to
the goal by doing "that" - and Impediments - I need Help with "something"
to bring us closer to the goal: "Who can help me?" The Daily Scrum is a Timebox of Max 15 min. Another reoccurring Scrum Event during the
Sprint - is the Product Backlog Refinement
Sometimes also in more general Agile Terms referred to as the Backlog Grooming The goal for this Event is to refine the highest
Prioritized Product Backlog Items of the Product Backlog. This refinement should be done to an extend
- where taking a Product Backlog Item into a sprint can be done confidentially and with
low risk. The Scrum Team decides How and When this Event
happens. As well as how many times it occurs during
a sprint. A Maximum of 10% of the Development Teams
Capacity can be used for this. Part of the activities in the Product Backlog
Refinement Event is - review and revise the Product Backlog Items
- for instance by Adding Details to them - Estimating the Effort needed to develop
the Product Backlog Items In rare occasions - the Sprint Goal becomes
obsolete. The Product Owner then - can decide to cancel
the entire sprint This Scrum Event is called a Sprint Cancellation
During the Event the - Product Backlog Items that are Done are
reviewed - If they are releasable - and the Product
Owner accepts these - well then they can be Released
- Remaining Product Backlog Items are re-estimated and put back into the Product Backlog And then it's time to start a new Sprint. A sprint is ended with 2 Scrum Events: The
first one is called a Sprint Review. It's an Informal meeting where the Product
Owner explains which PBIs are DONE and which are NOT DONE. The Development Team discusses the learnings
- What went WELL - What Problems did we face
- and what Solutions did we find to solve these The Development Team is Demo'ing the Work
that is Done. That's why this event in other Agile processes
sometimes is named The Sprint Demo Another outcome of the Scrum Review Event
could be other input for the coming Sprint planning. Part of the activities also include Review
of any changes in Markets and changes in potential Use of the product that is being produced. The Product Owner invites the Key stakeholders
to participate in the Event. This is one of the few Scrum Events where
people outside the Scrum Team are participating. Product Owner Tracks Total work remaining
at least at every Sprint Review. He Compares it with previous Sprint Reviews
to Asses progress towards End Goal by desired time left. This progress must be Transparent to all stakeholders. This Event - The Sprint Review - is also an
opportunity to Inspect and Adapt. It's time boxed to a duration of maximum 4
hours for a 1 month sprint. As mentioned - a Sprint ends with 2 Scrum
Events. The Second one is called a Sprint Retrospective
The goal of this event is to make the next sprint more effective and enjoyable The topic discussed in this Event is
How last sprint went regarding: - People
- Relationship - Process
- Tools And the Outcome - is:
- What went well - Potentially improvements
- and a Plan - for implementing these improvements Review of “Definition of Done” could also
be part of the Event - to increase Product Quality. Again this Event is an opportunity to Inspect
and Adapt It's time boxed - to a duration of maximum
3 hours for a 1 month sprint. After this detailed look at the Scrum Events
- It's time to take a look at the Artifacts of the Scrum Framework. As you already know by now - In Scrum the
Requirements catalogue is called a Product Backlog. The content of the Product Backlog must be:
- Visible - anyone should be able to see it - It must be Transparent and Clear to all
- anyone should be able to understand it’s content
- It should be an Ordered/prioritized list - it must be possible to see what is most
important - what is least important - end everything in-between these two
- It should be Dynamic - it is in constant change and evolves over time
- And it should be able to Show what the Scrum team will work on next The attributes of the Product Backlog Items
are: - Description (what is it that needs to be
done and why) - Estimate (how much effort is involved in
delivering this) - Value (what is the benefit of getting this)
- Order (how is it prioritized compared to other Product Backlog Items)
- Grouping (is it part of a group of several requirements)
- and is it's Ready or Not for the next Sprint Planning In Scrum we employ a strategy of giving most
attention - most time in grooming - to the highest prioritized Product Backlog item. So the higher priority a Product Backlog Items
has - the Clearer and more detailed the description
should be - and the More precise the estimate should
be This makes sense as the Highest prioritized
Items - are the next ones - that should be included in the coming sprint planning. And the opposite can be said for the lower
prioritized Product Backlog Items: - They have Fewer details
- And Rougher estimates When Changes in Business Requirements, Market
conditions and technology occurs - this will immediately affects the Product
Backlog and it's content. The final Artifact within Scrum - is the Product
Increment Sometimes it's also labelled with as many
words as Potential Releaseable Usefull working Product
Increment The Product Increment must Adhere to the Definition
of Done Criterias: These definitions could be on a
- System/Product level Or on the
- Organisation level And that - more or less - is what the Scrum
Framework consists of. We have been through the 3 Roles:
- The Development Team - The Scrum Master
- and The Product Owner All 3 together also known as the The Scrum
Team Beside the Sprint - as it's the container
of all the other Events - there are 5 standard Scrum Events
- The Sprint Planning - The Daily Scrum
- The Sprint Review - The Sprint Retrospective
and - The Product Backlog Refinement (or grooming if you will) And then there’s the exception
- The Sprint Cancellation And off course a handful of Artifacts
- The Product Backlog - The Sprint Backlog
- The Sprint Goal - The Burndown chart
- And off course the Product Increment As you perhaps recall from the beginning of
the video - I mentioned that there were 4 components in the Scrum Framework. So beside the Roles, the Events and the Artifacts
- there are Rules. The rules is I've tried to describe in the
explanations - during my Tour of Scrum by the book. And in the Graphical Overview I've left these
as bullets next to the Roles, The Events and the Artifacts. Do Notice that this presentation is my interpretation
of what Scrum by the book is. If you really would like to dig further into
Scrum - then please download The Scrum Guide - The definitive Guide to
Scrum: The rules of the Game. This is written and maintained by the fathers
of Scrum Jeff Sutherland and Ken Schwaber. And can be found at this url:
https://www.scrum.org/scrum-guide As mentioned in the Overview - the format
and look and feel of this presentation is heavily inspired by Henrik Kniberg’s video
on Product Ownership in a Nutshell This is an absolutely must see - for anyone
working with Scrum or any other Agile Methodology It can be found at this url:
http://blog.crisp.se/2012/10/25/henrikkniberg/agile-product-ownership-in-a-nutshell Do also check out Henrik Knibergs Checklist
for Scrum and his books. I also really like Mike Cohns presentation
on Scrum. And not just because I've been allowed to
translate it into the Danish language. It can be found at this url:
http://www.mountaingoatsoftware.com/agile/scrum/a-reusable-scrum-presentation This and other Videos and presentations can
be found at my youtube channel Check it out at this url:
http://www.youtube.com/user/perbeining And Agile inspiration in general can be found
at my blog and Suitcase At this URL:
http://www.beining.dk Twitter: #perbeining Finally the end-result of my sketching throughout
this video - is also downloadable as a graphics file. Find it at this url:
http://www.beining.dk/scrum And as mentioned at the beginning of this
presentation of Scrum by the book: Please get back to me - either in the comments,
by email or by twitter - should you have suggestions for how I could improve my world view or interpretation
of Scrum by the Book. And should there be other Agile concepts you
would like to have explained in this format - please also let me know. That it. I’m Per Beining
Stay Agile in mind - until next time we touch base Bye-bye!
