5. Events of the SCRUM Process
•SCRUM teams will
hold a retrospective
meeting at the end
of each sprint so
that all team
members can give
input on what is
working well and
what is not working
well.
1.What worked well
during the last
sprint?
•2.What did not work
very well during the
last sprint?
•3.What should we
improve?
Sprint
retrospective
•At the end of a
sprint, the
SCRUM Master
will organize a
sprint demo
where the items
of the sprint that
have just ended
can be shown to
key stakeholders.
Anyone in the
company who is
interested can
turn up and
watch the team
demonstrate wh
at they have
built.
Sprint demo
•The daily
stand-up is a
daily meeting
of no more
than 15
minutes
where each
member of
the team gives
a brief update
of how their
work is
progressing.
Daily stand-up
•The process of
selecting
which items to
work on
during the
sprint is done
during the
sprint
planning
meeting.
Sprint
planning is
time-boxed to
a maximum of
8 hours.
Sprint planning
•A
sprint is usuall
y 1-week to 4-
week
duration. The
team
will attempt
to begin,
finish, and
release work
during this
time
The sprint
IHEB OMRI 5
6. •A product backlog is a living document, which means it changes and gets updated as
the team learns more, as market conditions change, as competitors bring out new
products, and as customers give input into what they need.
•For each item in the product backlog, you should add some additional information:
•Description
•Order (as in the priority order within the whole backlog list)
•Estimate
•Value to the business
Product backlog
•After the sprint planning, the team has committed to a developed plan to work on a
chosen set of items in the next sprint.
•Those items are then removed from the product backlog and moved into the sprint
backlog. The sprint backlog is guided by the sprint goal (which is the stated outcome
objective of the sprint)
Sprint backlog
•A burndown chart is a graphical representation of the amount of estimated remaining
work. Typically the chart will feature the amount of remaining work (perhaps in
hours) on the vertical axis with time along the horizontal axis.
Burndown charts
•The most important artifact is the actual product improvements, or in other words,
the new code which has been written to enhance the features or usability of your
product.
Product increment
IHEB OMRI 6
9. Step 1. Product Backlog Creation
Step 2. Sprint Planning and Sprint Backlog Creation
Step 3. Working on the Sprint. Scrum Meetings
Step 4. Testing and Product Demonstration
Step 5. Retrospective and Next Sprint Planning
IHEB OMRI 9
10. Step 1. Product Backlog Creation
The product backlog is the core deliverable that maintains and evolves the requirements in an agile environment.
Ownership by the product owner.
A product backlog contains a complete list of all requirements under consideration (written using a user story syntax –
more on that below), rank ordered, and matrixed with other key characteristics that facilitate planning and prioritization.
The most important items are shown at the top of the product backlog so the team knows what to deliver first. The
development team doesn't work through the backlog at the product owner's pace and the product owner isn't pushing work
to the development team. Instead, the development team pulls work from the product backlog as there is capacity for it.
A team's roadmap and requirements provide the foundation for the product backlog. Roadmap initiatives break down into
several epics, and each epic will have several requirements and user stories.
The product owner then organizes each of the user stories into a single list for the development team. The product owner
may choose to deliver a complete epic first. Or, it may be more important to the program to test booking a discounted
flight which requires stories from several epics.
IHEB OMRI 10
11. Product backlog prioritization
The product backlog itself is owned by the product owner. The product owner’s job is to
produce the very best product possible, so that means developing the most valuable
additions to the software first. Since the product backlog is ranked in order of most
valuable components, it would stand to reason that the most valuable addition would
be at the very top. But that’s not necessarily the case, as the most valuable addition
likely has dependencies that need to be developed first.
Higher-priority items should be refined and have great value to the product.
Mid-priority items should be candidates for refinement (the process of detailing each
task)
Low-priority items should not be a dependency and can be safely ignored until they
are candidates for refinement.
As items progress closer to the top of the list to be added to the next sprint cycle, they should
be refined so they can be better acted upon.
IHEB OMRI 11
12. Once the product backlog is built, it's important to regularly maintain it to keep pace with the program. Product owners
should review the backlog before each iteration planning meeting to ensure prioritization is correct and feedback from the
last iteration has been incorporated. Regular review of the backlog is often called "backlog grooming" in agile circles(some
use the term backlog refinement).
Once the backlog gets larger, product owners need to group the backlog into near-term and long-term items. Near-term
items need to be fully fleshed out before they are labeled as such. This means complete user stories have been drawn up,
collaboration with design and development has been sorted out, and estimates from development have been made. Longer
term items can remain a bit vague, though it's a good idea to get a rough estimate from the development team to help
prioritize them. The key word here is "rough": estimates will change once the team fully understands and begins work on
those longer term items.
The backlog serves as the connection between the product owner and the development team. The product owner is free to
re-prioritize work in the backlog at any time due to customer feedback, refining estimates, and new requirements. Once
work is in progress, though, keep changes to a minimum as they disrupt the development team and affect focus, flow, and
morale.
Keeping the backlog healthy
IHEB OMRI 12
13. Product refinement is the process of refining the tasks in the product backlog so that they’re clear enough to be action
items instead of nebulous ideas.
PBR is a collaborative discussion process which starts at the end of one sprint to confirm whether the backlog is ready for
the next sprint.
The Objective of PBR meeting:
A lot of time is saved at sprint planning meetings, if the backlogs are well maintained. If the backlog item is clearly
specified in the acceptance criteria and cross-checked properly by the team members, the planning process can be
accomplished prior to the meeting. PBR offers the team members the opportunity to interact with each other regarding
stories.
Why is PBR important?
PBR and its sessions are important mainly due to the following features-
•It increases the efficiency of the team by reducing uncertainty
•Properly refined stories are easy to estimate, test and implement.
•PBR session increases the efficiency of the team due to the knowledge shared among the team members.
•If PBR meeting is maintained properly, it helps reduce the time for a Sprint planning meeting.
Product Backlog Refinement (PBR)
IHEB OMRI 13
14. Step 2. Sprint Planning and Sprint Backlog Creation
A sprint planning meeting is conducted before the start of a sprint. The purpose of this meeting is to determine the sprint
plan and set a sprint goal.
Sprint planning includes agreeing on the number of backlog items in the sprint that is the responsibility of the
development team and as well as to define the goal for the current sprint and sprint backlog.
During the sprint planning meeting, the product owner describes the highest priority features to the entire team. They will
then discuss which stories the team will do in that sprint. The meeting should be attended by the whole team. If additional
expertise on specific backlog items are required, then stakeholders can be also invited. The team may include the
refinement sessions as well.
IHEB OMRI 14
15. Sprint Planning Meeting – Part I
Part one of the sprint planning meeting is a review of the product backlog items the Product Owner will ask the team to
forecast and deliver. This is the time for the product owner to describe what he wants to make available by the end of the
next sprint. During this part of the meeting, it is not uncommon for the team to banter back and forth with the product
owner, asking clarifying questions and driving away ambiguity. By the end of sprint planning part one, the team will
select a sprint goal: a one-sentence description of the overall outcome of the sprint. This helps later when questions about
depth and breadth come up: if the work does not directly tie to the sprint goal, then it is not done during the sprint. The
key activities to be conducted in Part I of the Sprint Planning Meeting are:
•During the first session the Product Owner presents the highest priorities of the Product Backlog to the team.
•Set the sprint goal or objective – Product Owner together with the development team think of the objective of the sprint.
•The team and the Product Owner collaborate to help the team determine what functionality can be delivered in the
upcoming Sprint.
•The team commits to this Product Backlog at the end of the session – Selected Product Backlog.
IHEB OMRI 15
16. Sprint Planning Meeting – Part II
The team decides how the work will be built. In this meeting the team will begin decomposing the product backlog items
into work tasks and estimating these in hours. The product owner must be available during this meeting but does not have
to be in the room. In fact, many teams find it helpful to work without product owner during this detailed part of the
meeting. Knowing that the product owner is available yet not having her observing all of the discussion about the best
way to implement a feature can be freeing for many teams. The key activities of the Part II of Sprint Planning are:
•During the second session of the meeting, the team plans how it will meet this commitment by detailing its work
as a plan in the Sprint Backlog.
• Detail planning – Breakdown stories into tasks, ensure the team has separated the stories into tasks, as this will
enable the team to consider everything that should be done to finish the stories. It’s additionally great practice to
make Testing as a different task.
• Estimating of the stories – Teams can do the measuring of the stories utilizing strategies like Planning Poker or T-
Shirt Sizing and Allow team members to sign up for the work they choose and give an estimate as for how long
each task will take to complete.
IHEB OMRI 16
17. Step 3. Working on the Sprint. Scrum Meetings
All team members are required to attend scrum meetings. Since both the Scrum Master and product owner are committed
team members, they are expected to attend and participate. Anyone else (for example, a departmental VP, a salesperson or
a developer from another project) is allowed to attend, but is there only to listen. This makes scrum meetings an excellent
way for a Scrum team to disseminate information .
The daily scrum meeting is not used as a problem-solving or issue resolution meeting. Issues that are raised are taken
offline and usually dealt with by the relevant subgroup immediately after the meeting. During the daily scrum, each team
member answers the following three questions:
1.What did you do yesterday?
2.What will you do today?
3.Are there any impediments in your way?
By focusing on what each person accomplished yesterday and will accomplish today, the team gains an excellent
understanding of what work has been done and what work remains. The daily scrum meeting is not a status update
meeting in which a boss is collecting information about who is behind schedule. Rather, it is a meeting in which team
members make commitments to each other.
IHEB OMRI 17
18. Step 4. Testing and Product Demonstration
Members that attend the meeting are: The Scrum Team and stakeholders (users, other teams, managers, investors,
sponsors, customers, etc.)
•The Product Owner opens the meeting and tells the attendees what the Development Team completed during the current
Sprint (what has been "Done" and “not Done”).
•The Development Team demonstrates the "Done" functionality (Demo), answers the questions and discusses problems
they met on their way.
•The Product Owner discusses the current state of the Product Backlog, marketplace changes, and forecasts the likely
release dates.
•The attendees collaborate on the Product Backlog Items, which can be completed during the next Sprint. Thus, the
stakeholders get a shared understanding of the future work.
•A review of the budget, timeline, potential capabilities follows.
IHEB OMRI 18
19. The Sprint Review is not just about product demonstration, it is an inspection of the completed Sprint, the Product
Backlog and the marketplace.
Also, it is a place for reviewing budgets, timeline and capabilities. Each Sprint is an important risk mitigation tool and
the Sprint Review is a decision point for the Product Owner.
Each Sprint can be the last one. The Product Owner makes a formal decision
regarding financing the next Sprint during the Sprint Review.
Here are some decisions that can be formally made:
•Stopping/Pausing the development
•Financing the next Sprint
•Adding team(s) with an assumption that it will speed up the development
•Releasing Increment (can be done anytime during the Sprint)
IHEB OMRI 19
20. Step 5. Retrospective and Next Sprint Planning
As described in the Scrum Guide, the Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and
create a plan for improvements to be enacted during the next Sprint.
The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. This is at most a three-
hour meeting for one-month Sprints. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the
event takes place and that attendants understand its purpose. This is the opportunity for the Scrum Team to improve and
all member should be in attendance.
During the Sprint Retrospective, the team discusses:
•What went well in the Sprint
•What could be improved
•What will we commit to improve in the next Sprint
IHEB OMRI 20
21. The Scrum Master encourages the Scrum Team to improve its development process and practices to make it more
effective and enjoyable for the next Sprint. During each Sprint Retrospective, the Scrum Team plans ways to increase
product quality by improving work processes or adapting the definition of “Done” if appropriate and not in conflict with
product or organizational standards.
By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the
next Sprint. Implementing these improvements in the next Sprint is the adaptation to the inspection of the Scrum Team
itself. Although improvements may be implemented at any time, the Sprint Retrospective provides a formal opportunity to
focus on inspection and adaptation.
IHEB OMRI 21
24. •The product owner creates a PBI or a tester creates a bug in the New state with
the default reason, New backlog item
•The product owner moves the item to Approved after it is sufficiently
described and ready for the team to estimate the level of effort. Most of the
time, items near the top of the Product Backlog are in the Approved state, while
items toward the middle and bottom are in a New state
•The team updates the status to Committed when they decide to commit to
working on it during the sprint
•The item is moved to the Done state when the team has completed all its
associated tasks and the product owner agrees that it has been implemented
according to the Acceptance Criteria.
PBIs and bugs follow this typical workflow progression:
IHEB OMRI 24
25. 6 Best Practices to Start a Scrum Project1. Create the Product Vision & Product Backlog
Together
Often the customer has an idea about the product and its
possibilities but a Product Backlog is still missing. A
good practice is to organise a workshop with the
customer and the supplier’s Development Team and
letting them create the Product Backlog together. Even
before setting up the contract. Ideally you also create the
product vision to ensure mutual understanding. By
creating the product vision and Product Backlog
together the customer and supplier really get to know
each other. More important: the customer meets the
actual Development Team. They are the ones who are
going to realise his dream. They are the ones he needs to
trust.
2. Estimate the Implementation Effort of the Product
Backlog Together
After creating the Product Backlog together it’s also
possible to estimate it in the presence of the customer.
The advantage is the customer hears all the discussions
& questions and can answer them directly. Possible
complexity is also detected and discussed together
which ensures mutual understanding about the given
estimations.
IHEB OMRI 25
26. 3. Determine the Business Value of the Product Backlog
Together
When the Product Backlog is estimated in implementation
effort, the next step is determining the business value. This is
up to the stakeholders. In the same session, facilitate the
stakeholders to discuss and determine the business value for
every Product Backlog Item using business value points. The
goal is a shared understanding of the priorities and inviting
the stakeholders to participate in defining what is more
valuable. This exercise forces them to prioritize the Product
Backlog without delegating this responsibility entirely to the
Product Owner.
After estimating the implementation effort (done by the
Development Team) and determining the business value
(done by the stakeholders) the following matrix will appear.
This offers great insights like:
•PBI D, E, F and G have a low implementation effort and
lot’s of business value. So start with these items first.
•PBI H and I will take quite some effort to implement and
won’t offer much business value. So do we really want
this on the Product Backlog?
4. Clarify Dependencies Between Product
Backlog Items
When the implementation effort and business
value is determined for every Product Backlog
Item, it’s time to detect the dependencies.
Technical dependencies can be clarified by the
Development Team, functional dependencies
might also be detected by the Product Owner
and stakeholders. This offers insights like:
•PBI C is a bottleneck. Discuss this item in
more detail to solve the dependencies.
•PBI J and K also have a dependency, so take
this into account when ordering the Product
Backlog
IHEB OMRI 26
27. 5. Invite the Customer to the Scrum Events
Invite the customer to all the Scrum events. Let the customer
experience how the Daily Scrum is done, let them experience
the discussions during the Sprint Planning and share all the
lessons learned during the Sprint Review. Most important of
course is to gather feedback about the delivered product and
evaluate the collaboration.
6. Decide Sprint Length
The Sprint length (which should be kept constant) should
be decided. It should not be too long, in order to avoid
“water fallising” the sprints and reduce the rhythm of
delivery. Not too short, in order to allow meaningful
value built in the increment. In any cases, it should be
kept within the limits set by the framework (i.e. 4 weeks
at maximum). Consider also organizational limitations or
guidelines (e.g. Predefined release dates, shared testing
infrastructure availability, etc).
IHEB OMRI 27
28. Do user stories replace a requirements document?
Agile projects, especially Scrum ones, use a product backlog, which is a
prioritized list of the functionality to be developed in a product or service.
Although product backlog items can be whatever the team desires, user
stories have emerged as the best and most popular form of product backlog
items.
While a product backlog can be thought of as a replacement for the
requirements document of a traditional project, it is important to remember
that the written part of an agile user story (“As a user, I want …”) is incomplete
until the discussions about that story occur.
It’s often best to think of the written part as a pointer to the real requirement.
User stories could point to a diagram depicting a workflow, a spreadsheet
showing how to perform a calculation, or any other artifact the product owner
or team desires.https://www.mountaingoatsoftware.com/agile/user-stories
IHEB OMRI 28