Tip:
Highlight text to annotate it
X
Hi and welcome to Scrum by the Book
Hi and welcome to Scrum by the Book - an overview
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 and 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 our youtube channel - where it can be found.
I'm Per Beining from goAgile. 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
Theres 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, Events and 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 take a look at 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 (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 the 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 be started.
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 activities and
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 Burnup Chart.
The Burndown chart gives an overview of how much work remains until 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 Scrum framework - and are most certainly not part of the Scrum team - they are outside
- but has been included 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:
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 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 none 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 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 given 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 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.
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. An 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 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 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 Masters 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 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 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 Requirement. - 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. The
Product Backlog Items is Broken down into manageable chunks - called Tasks.
Also the Sprint Goal is part of the Artifacts being delivered.
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
The Goal of the Daily Scrum is to optimize the probability for the Team to reach it's Sprint Goal.
The Inpection 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 slash
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. 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
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.
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 Product Owner accepts these - and are 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 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 *** 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 detailsd 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
- Transparent and Clear to all - anyone should be able to understand its content
- Ordered/prioritized list - it must be possible to see what is most important - what is least
important - end everything in-between these two
- 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
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 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: - Development Team
- Scrum Master - and Product Owner
All 3 together also known as 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 theres 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 - given 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 Knibergs 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 goAgiles youtube channel
Check it out at this url: http://www.youtube.com/user/goagiledk
And Agile inspiration in general can be found at the goAgile blog and our Suitcase
At this URL: http://www.goagile.dk/suitcase/
Twitter: #goAgileDK
Finally the end-result of my sketching throughout this video - is also downloadable as a graphics
file. Find it at this url:
http://www.goagile.dk/suitcase/scrum-by-the-book/
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. Im Per Beining
Stay Agile in mind - until next time we touch base
Bye-bye!