1. Can you explain the Product Owner role in a few sentences?

The Product Owner (PO) is responsible for maximizing the value of the
product by prioritizing and managing the product's features. The PO acts
as the primary contact between the Scrum Team and external
stakeholders and is accountable for understanding business needs,
gathering feedback, and ensuring that the product delivers maximum
value.

2. Why isn’t it required for the Product Owner to be technical?

The Product Owner's role is business-oriented, focusing on maximizing
value rather than the technical details of product development. Their
primary responsibility is understanding customer and stakeholder needs,
translating those into product features, and prioritizing them based on
value. While technical knowledge can be helpful, the PO’s expertise in
business and value generation is key.

3. How does the Product Owner affect the value of the product?
The Product Owner directly impacts the product's value by deciding which
features are developed and in what order. They prioritize features that
generate the most value for the customer, balancing the cost of
development with the potential benefits to ensure the product aligns with
the business goals and maximizes profitability.

4. The Product Owner is the main contact point between the team
and the external stakeholders. Does it mean that stakeholders
should not contact the developers directly?
No, stakeholders can still contact developers directly, especially for tasks
like user acceptance testing, but most communication and information
flow should go through the Product Owner. This ensures that the feedback
and needs from stakeholders are analyzed, consistent, and aligned with
the overall product vision.

5. Is it alright to have a committee playing the role of Product

Owner in a big project?
While a committee can support the Product Owner role in large projects,
only one person should hold the official title of Product Owner. This
individual will make the final decisions and act as the formal point of
contact, ensuring clarity and accountability.

6. What are the main characteristics of the Development Team?

The Development Team is cross-functional, meaning it has all the skills
necessary to develop the product without relying on external departments.
It is also self-organized, meaning the team makes its own decisions on how
to complete its work, and they share accountability, meaning everyone in
the team is responsible for the overall success of the project.

7. Who’s the manager in a Scrum Team?

There is no formal manager in a Scrum Team. The team operates in a flat
hierarchy, with all members, including the Product Owner and Scrum
Master, working at the same level. Decision-making power is shared, with
specific responsibilities allocated by role rather than managerial authority.

8. Are there testers in Scrum?

No, there are no designated testers in Scrum. Instead, everyone on the
Development Team is referred to as a developer, regardless of their area of
expertise. A developer may specialize in testing, but they share
accountability for all aspects of the product, including design, coding, and
testing.

9. What is Scaled Scrum?

Scaled Scrum refers to using Scrum principles and frameworks when the
project is too large for a single team. In such cases, multiple Scrum Teams
collaborate to develop the product. The course mentions that only a few
concepts of Scaled Scrum will be covered later, indicating that it's a
broader approach to managing large projects with multiple teams.

10. What is the difference between responsibility and

accountability?

The difference between responsibility and accountability lies in their

focus and ownership:

1. Responsibility is task-focused and refers to overseeing a

specific duty or assignment. A person is responsible for ensuring that tasks
are completed correctly, and multiple people can share responsibility for a
task.
2. Accountability is results-focused and refers to taking
ownership of the outcomes of a task or decision. It involves answering for
the success or failure of the task and is tied to personal choice and action.
Accountability cannot be shared; it belongs to one person who must
explain and own the results.

1. What should the Product Owner do first when starting a new

project?

• The Product Owner should ask “why” repeatedly to fully

understand the problem the project aims to solve. They need to focus on
the reason behind the project, rather than jumping straight into solutions
or features.

2. Why is it important to focus on the problem before the

solution?

• Focusing on the problem helps to ensure the solution actually

addresses the real issue. Jumping to solutions without fully understanding
the problem may lead to unnecessary features or projects that don’t
deliver real value.
3. What story is used in the transcript to illustrate this approach,
and what was the lesson?

• The story of the elevator manufacturer is used, where instead

of speeding up the elevators, mirrors were installed to reduce the
perceived wait time. The lesson is that solving the real problem
(boredom), not just the symptom (slow elevators), can lead to a better
and more creative solution.

4. What document is recommended to capture the “why” of the

project?

• The Product Vision document is recommended to capture the

reasons behind creating the product. This is not explicitly required by the
Scrum Guide, but it’s a good practice in Scrum to clarify the product’s
purpose and direction.

5. How is the Product Vision similar to documents in other project

management methodologies?

• The Product Vision is similar to the Project Charter in PMBOK

or the Project Brief in PRINCE2, which both identify the reasons for doing
a project.

6. Why does the lesson emphasize the importance of asking

“why”?

• Asking “why” helps the Product Owner understand the core

reasons behind the project, ensuring the product solves the right problem
and aligns with the company’s or end-users’ needs.
1. What is the next step after defining the Product Vision in a new
project?

• The next step is to start thinking about the product features

and create a Product Backlog. The Product Backlog is a prioritized list of
features, which is the main tool the Product Owner uses to maximize the
product’s value.

2. What is the Product Backlog?

• The Product Backlog is a list of features or requirements for

the product. It includes all the items the team needs to work on, and it
evolves throughout the project based on customer feedback, development
progress, and new ideas.

3. How should a Product Owner gather information for the Product

Backlog?

• The Product Owner talks to various stakeholders such as

customers, end-user representatives, and the Development Team to
gather information on what is needed. The PO should analyze the
information, remove inconsistencies, and refine it to create well-
defined items for the Product Backlog.

4. How are Product Backlog items prioritized?

• Items are initially prioritized based on their value to the

customer or end-user. However, the transcript hints that this is not the
perfect method, and there will be more refined ways of prioritizing
discussed later in the course.

5. Why shouldn’t the Product Owner create a complete Product

Backlog at the beginning of the project?

• In Scrum and Agile, the Product Backlog is not static. The

team will continuously refine, add, and remove items as the project
evolves. A complete Product Backlog at the start is impractical since new
insights and feedback will emerge during development.

6. What is the significance of focusing on the most important

items in the Product Backlog?

• By focusing on the most valuable features first, the team

ensures that even if the project is stopped early, the most important
functionality has already been delivered. This approach also helps guide
the project and allows for flexibility in development.

7. How does the concept of Agility relate to the Product Backlog?

• Agility in Scrum means that the Product Backlog evolves as

new feedback and ideas are incorporated. The Product Owner adds,
removes, and refines items continuously, ensuring that the product
remains aligned with the customer’s needs and business goals.
1. When can we start the first Sprint?

• The first Sprint can start after the Product Owner has created a
simple version of the Product Backlog with a few initial items. Once
the Product Backlog is ready with the prioritized features, the team is
ready to begin the Sprint.

2. What’s an “Increment”? What’s the important characteristic of

Increments?

• An Increment is a new version of the product created each

time an Item is finished. The important characteristic of Increments is that
they must be releasable or, as the Scrum Guide specifies, potentially
releasable, meaning they are in a usable state and can be delivered to
the customer if needed.

3. What are the two outputs of Sprint Planning?

 • The two outputs of Sprint Planning are:
1. The Sprint Backlog, which includes the selected items from
the Product Backlog for the Sprint.
2. The Sprint Goal, which is a specific objective or focus for the
Sprint, similar to the Product Vision but for that Sprint alone.

4. Who decides about the number of items for the Sprint Backlog?
Why?

• The Developers decide how many items to include in the

Sprint Backlog because they are self-organized and understand best how
much work they can complete during the Sprint. They have the autonomy
to make this decision.

5. What are the two types of elements in a Sprint Backlog? When

are they defined?

• The two types of elements in a Sprint Backlog are:

1. Product Backlog Items: The features selected from the
Product Backlog.
2. Tasks or Activities: These are the smaller tasks needed to
complete each selected item. Initially, only a few tasks are created for the
top items, and more are added as the Sprint progresses.

6. What’s the timeboxed duration of Sprint Planning in a one-

month Sprint?

• For a one-month Sprint, Sprint Planning is timeboxed to

eight hours. This is the maximum time allotted to plan the upcoming
Sprint and create the Sprint Backlog and Sprint Goal.

1. What’s the main purpose of Daily Scrums?

• The main purpose of Daily Scrums is for the developers to

synchronize with each other on the progress of the project. It helps the
team stay aligned and address any issues that might impact their work.

2. What’s the timeboxed duration of Daily Scrums?

• The Daily Scrum is timeboxed to 15 minutes.

3. What are the three questions that developers probably answer

in the Daily Scrum?

• The three traditional questions developers answer in the Daily

Scrum are:
1. What did I do since yesterday?
2. What am I going to do until tomorrow?
3. What problems or obstacles do I have?
4. What’s the type of diagram that is usually used on Agile
projects for visualizing progress?

• The diagram used to visualize progress in Agile projects is the

Burn-Down Chart. It shows the remaining work over time.

5. What should be done when an item is done during the Sprint?

• When an item is done, the developers should call the Product

Owner to review and ensure the item is really “done,” confirming it meets
the Definition of Done.

6. When is something considered “Done”?

• An item is considered “Done” only when it meets the

Definition of Done, which may include things like user acceptance
testing and any other specific criteria outlined by the team.

7. What would you do with an item that is not “Done” until the
end of the Sprint? Why?

• If an item is not “Done” by the end of the Sprint, it should be

returned to the Product Backlog rather than automatically moved to
the next Sprint Backlog. This allows the Product Owner to refine and re-
prioritize the item based on new insights, such as complexity or changing
value.

8. When do we do user acceptance testing in Scrum? Why?

• User acceptance testing is done as soon as possible

during the Sprint and before an item is considered “Done.” This ensures
that the item is truly complete and ready for feedback, avoiding the
accumulation of unfinished work that would disrupt the feedback loops.

9. Who’s responsible for creating the Definition of Done?

• The developers are responsible for creating the Definition of

Done because they are the ones who understand the technical
requirements and criteria for an item to be completed.

10. What can be done when the developers are done with all
items in the Sprint Backlog and there’s still time until the end of
the Sprint?

• The developers have two options:

1. Work on improving existing work, such as refactoring
code or researching potential improvements for future Sprints.
2. Pull new items from the Product Backlog into the Sprint
Backlog and start working on those.
1. When do we end Sprints?

• Sprints are timeboxed, meaning they end when the timebox

duration is over, not when all the items in the Sprint Backlog are
completed.

2. Why is it important for the Increments to be potentially

releasable?

• Increments need to be potentially releasable because it

ensures that the product is in a state where it can be delivered to the
customer if needed, which facilitates better feedback during the Sprint
Review.

3. What are the two main things that we do in the Sprint Review?

• In the Sprint Review, we:

1. Show the new features to the customer and let them
interact with the product.
2. Evaluate the project’s performance and communicate a
forecast for the project’s completion date.

4. Is Sprint Review the only time for receiving feedback from the
customer?

• No, the Sprint Review is just one structured way to receive

feedback. The customer can still work with the product and provide
feedback outside the review.

5. What’s the timeboxed duration of Sprint Reviews in one-month

Sprints?

• The Sprint Review is timeboxed to four hours for a one-

month Sprint. If the Sprint is shorter, the Sprint Review duration is
proportionally shorter.

6. What’s the main purpose of Sprint Reviews?

• The main purpose of Sprint Reviews is to gather feedback

from the customer, which is used to refine the Product Backlog and plan
future Sprints.

7. What’s the main purpose of Sprint Retrospectives?

• The main purpose of Sprint Retrospectives is to reflect on how

the team has been working and to identify improvements that can be
implemented in the next Sprint for continuous improvement.

8. What’s the timeboxed duration of Sprint Retrospectives?

 • The Sprint Retrospective is timeboxed to three hours for a
one-month Sprint. For shorter Sprints, it is proportionally shorter (e.g., 1.5
hours for a two-week Sprint).

9. What happens between two Sprints?

• There is no time between two Sprints. As soon as the Sprint

Retrospective ends, the next Sprint Planning begins, often immediately or
the next day. Therefore, the Product Backlog must be refined during the
Sprint to be ready for the next Sprint Planning

1. Why don’t we have a specific, timeboxed event for Product

Backlog refinement?
• Scrum does not have a specific, timeboxed event for Product
Backlog refinement because refinement is an ongoing process. The
Product Backlog is constantly updated and refined based on feedback from
customers, developers, and other stakeholders. Refinement can happen at
any time during the project as needed, rather than at a fixed moment.
2. Describe everything that happens during Product
Backlog refinement.
• During Product Backlog refinement, the Product Owner:
• Adds new items to the Product Backlog based on customer
feedback, end-user input, or new ideas.
• Breaks down larger items into smaller, more manageable
ones.
• Removes unnecessary items that are no longer relevant.
• Collaborates with developers to ensure the items are
realistic and properly aligned with the project.
• Asks developers for estimates on the size or effort required
for each item.
• Refines estimates and details to improve clarity and help
prioritize items effectively.
• The process is iterative and involves continuous interaction
with both customers and developers.
3. How much time should we spend on Product Backlog
refinement?
• Product Backlog refinement should not take more than
10% of the developers’ time during a Sprint. However, the Product
Owner can spend as much time as necessary on refinement, ensuring that
the Backlog is ready for the next Sprint Planning.
4. Who’s responsible for estimating the size of items?
Why?
• The developers are responsible for estimating the size of the
items because they are the ones who will be doing the actual work and
have the best understanding of the effort required to complete each item.
Their technical expertise allows for more accurate estimations of the work
involved.

1. Agile vs. Predictive Development:

 • Predictive development involves planning everything
upfront. You clarify expectations at the beginning, design the product, and
create a plan to follow throughout the project. This method works well for
projects where requirements are clear, such as building bridges or
satellites.
• Adaptive development (Agile) accepts that not all
expectations are clear from the start. It focuses on creating simple product
increments, showing them to the customer, gathering feedback, and
refining the next steps based on that feedback. This process is repeated
until the product meets the customer’s expectations.

2. Key Concepts in Agile:

• Agile is an adaptive approach to product development,

characterized by incremental steps and continuous feedback loops.
• Agile allows for progressive discovery of requirements and
expectations, especially in IT projects, where customers often don’t know
exactly what they want until they see working parts of the product.

3. Differences Between Predictive and Adaptive Systems:

• Predictive systems require upfront prediction and planning,

making them suitable for projects with fixed requirements.
• Adaptive systems allow for flexibility and are built on
feedback and adjustments at every stage.
• Agile is an adaptive system, focused on adjusting to changes
and refining the product through iterative cycles.

4. Terminology:

• Waterfall is the term often used in the IT community to refer

to predictive methodologies, though it is mostly used within IT and not in
other industries like construction.

5. Customer Feedback Importance:

• In Agile, customer feedback plays a critical role in defining

the next steps. The product is developed incrementally, and each
increment is used to further refine and clarify the customer’s needs.

6. Agile Is Not Just a Mindset:

• While some refer to Agile as a “mindset,” the transcript

emphasizes that Agile is a method or framework built around adaptive
systems, and calling it merely a mindset is incomplete.
Adaptive projects are driven by unclear or evolving requirements
rather than detailed upfront plans. Key factors that drive adaptive projects
include:
 1. Uncertain or Changing Expectations: In many projects,
especially IT-related ones, customers and end-users often don’t know
exactly what they want at the start. Adaptive projects allow for
flexibility as expectations become clearer through feedback loops.
2. Continuous Customer Feedback: Adaptive projects rely on
customer feedback after delivering small, incremental versions of the
product. This helps refine future work, making sure the final product aligns
with the customer’s actual needs.
3. Incremental Development: Instead of defining everything
upfront, adaptive projects focus on creating a minimal viable product
(MVP) or simple increment, testing it with the customer, and adjusting the
development approach based on the results.
4. Flexibility and Adaptation: Adaptive approaches such as
Agile emphasize the ability to adapt to changes quickly. Feedback from
each increment helps the team reassess priorities, features, and timelines
for the next cycle, ensuring the project remains aligned with real-time
needs.
5. Reduction of Risk: By delivering in increments, adaptive
projects reduce the risk of large-scale failure. Issues can be identified
early, and the project can be adjusted before too much time or money is
invested.
6. Focusing on Value: Adaptive methods prioritize the most
valuable features first, ensuring that each iteration delivers something
useful to the customer, even if the project is stopped early.

In summary, adaptive projects are driven by the need for continuous

learning and adjustment, allowing teams to develop products in
environments where upfront planning is not sufficient or where
requirements are expected to evolve over time.

1. Development Processes:

• The main steps in software development involve: Analyzing,

Designing, Building (Constructing), Integrating, and Testing.
• These are called Development Processes, and they can be
structured differently in various methodologies (e.g., merging or splitting
certain steps).

2. Predictive System (Waterfall):

• In a Predictive system, all the Development Processes

(Analyze, Design, Build, Integrate, Test) are done upfront.
• The complete scope of the project is defined before moving
forward, leading to a single product delivery at the end of the project.
• This method works for projects where requirements are
known in advance, such as in construction or space missions.
• The problem with using the Predictive system in IT projects is
that you deliver the product at the end, when customer expectations may
have changed or evolved.
3. Adaptive System (Agile):

• In an Adaptive system (Agile), the product is developed in

iterations (or Sprints in Scrum).
• Each iteration delivers a new increment of the product, which
contains additional features.
• Feedback from the customer is gathered at the end of each
iteration, allowing the team to adapt and modify the product based on
new insights.
• Iterative Development: In each iteration, the Development
Processes (Analyzing, Designing, Building, etc.) are repeated for a subset
of features. This enables the team to progressively refine the product.
• Incremental Delivery: The product is delivered
incrementally, with each iteration adding new features and enhancing the
product.

4. Key Concepts in Adaptive Development:

• Iterative Development: The Development Processes are

repeated in each iteration, allowing the product to be refined and adjusted
incrementally.
• Incremental Delivery: The product is built and delivered in
increments, with each iteration adding more features that bring the
product closer to completion.

5. Feedback-Driven Development:

• In the Adaptive system, instead of trying to predict customer

needs at the beginning, the team develops small increments, gathers
feedback from the customer, and adjusts accordingly.
• This feedback loop helps to clarify expectations and build a
product that meets the customer’s real needs.

6. Planning in Agile:

• Contrary to the belief that Agile doesn’t have planning,

Agile projects do have planning, but it’s ongoing and adaptive. Planning is
done incrementally based on feedback, rather than upfront as in
Predictive systems.

7. Comparison Between Predictive and Adaptive Systems:

• Predictive systems (Waterfall): All planning and design is

done upfront, and the product is delivered at the end of the project. It
works well for projects with fixed, well-known requirements.
• Adaptive systems (Agile): Planning, development, and
delivery happen iteratively, allowing for flexibility and adjustments based
on continuous feedback.

Iterative Development:
 • Process-focused: In iterative development, the same
development processes (Analyze, Design, Build, Integrate, Test) are
repeated in each iteration for a subset of the product’s features.
• Continuous refinement: Each iteration refines and improves
the product based on feedback from previous iterations. You don’t work on
the entire product at once; instead, you progressively develop parts of the
product and adjust as needed.
• Feedback-driven: Iterative development uses feedback from
the customer at the end of each iteration to enhance and adjust the
product before moving to the next iteration.

Incremental Delivery:

• Output-focused: Incremental delivery refers to the practice of

delivering the product in small, functional parts or increments. Each
increment adds new features or improvements to the product.
• Build on previous versions: With each iteration, you add
more features to the existing product, creating a new version. These
increments build upon one another, resulting in a more complete product
over time.
• Deliverable value: Each increment is potentially usable by
the customer, and each delivery provides working software that can be
tested and evaluated.

1. Planning in Predictive vs. Adaptive Systems:

• Predictive systems involve a large amount of upfront

planning. The plan includes defining the product, creating a detailed
design, and developing a roadmap at the beginning of the project.
However, the plan is dynamic and requires updates over time to account
for real-world changes.
• Adaptive systems (Agile) do not rely on detailed upfront
planning. Instead, they involve incremental planning at the start of each
iteration or Sprint. Planning is done in small, manageable chunks based
on the feedback and understanding gained from previous increments.

2. Agile Misconception:

• There is a common misconception that Agile projects don’t

involve planning. However, Agile does require planning; it is just done
continuously and adjusted throughout the project rather than being fixed
upfront.
• In Agile, planning and adaptation are intertwined, meaning
that teams continuously adapt their plans based on feedback and
changing requirements.

3. Different Agile Approaches:

 • Some Agile methods, like DSDM, have high-level upfront
planning (though not detailed), while others like Scrum have very
minimal upfront planning. The key is that Agile allows for adaptation to
feedback as the project progresses.

4. Sprint Backlog and Task Creation in Scrum:

• In Scrum, the Sprint Backlog is created at the beginning of

each Sprint. However, not all tasks are detailed upfront, as that would be
too rigid. Instead, only some tasks are planned initially, and new tasks
are added throughout the Sprint as needed. This allows for flexibility
in how work is completed.

5. Adaptation in Agile vs. Predictive Systems:

• In Agile, adaptation happens frequently through feedback

loops, with multiple product increments being delivered throughout the
project. These increments allow for continuous learning and adaptation
based on customer feedback.
• Predictive systems also have some level of adaptation, but it
is far less frequent and typically happens in response to external factors
(e.g., a change in materials for a building project).

6. Cone of Uncertainty:

• The Cone of Uncertainty is a concept in Agile that highlights

how there is more uncertainty at the beginning of a project, and as the
project progresses, the team learns more, reducing uncertainty. In
Predictive systems, plans are created when uncertainty is highest,
which can lead to challenges later in the project when actual conditions
differ from the predictions.

7. PRINCE2 and Gradual Planning:

• PRINCE2, a Predictive framework, includes a process where a

high-level plan is created at the start, and more detailed plans are made
at the beginning of each stage. This gradual detailed planning is similar to
Agile in terms of adapting to project developments but differs as it is not
entirely based on feedback loops like in Agile.

8. Agile and Different Project Types:

• While Agile is effective in uncertain environments, such as

software development, it may not always be suitable for projects with low
uncertainty, like construction or infrastructure, where clear
requirements are known upfront.

9. Adaptation vs. Detailed Upfront Planning:

 • Agile allows for a balance between planning and
adaptation: small plans for each iteration that adjust based on feedback.
In contrast, Predictive systems rely on upfront planning with less
frequent adjustments.
1. What makes Agile special?

• Agile’s life cycle makes it special, not just features like

collaboration, self-organized teams, or daily meetings, which exist in many
types of projects. Agile allows teams to adapt as the project evolves,
rather than planning everything upfront like in Predictive systems.

2. When should Agile be used?

• The first key question to ask is: Do I need to be adaptive?

• Agile is beneficial when requirements are unclear upfront
or are expected to change. Projects where there is a lot of uncertainty or
evolving expectations are well-suited for Agile.
• The second question to ask is: Can I use an Adaptive
system?
• Agile projects require repeating development processes
and delivering increments that are usable or testable. If this is not
possible, Agile may not be a good fit.

3. Why might Agile not be applicable to all projects?

• Agile is not always feasible because it relies on iterative

development (repeating processes) and incremental delivery
(delivering usable parts of the product).
• For certain projects like building construction, where all
design must be completed upfront (e.g., designing a foundation), or where
it is not possible to deliver usable increments (e.g., an unfinished building),
Predictive systems are more appropriate.

4. What types of projects are better suited for Predictive systems?

• Construction projects, like building an airport or a large

infrastructure, are better suited for Predictive systems because they
require detailed upfront design and planning. The nature of these projects
doesn’t allow for delivering usable increments during development.
• Projects like upgrading operating systems or creating
networking infrastructure are also closer to Predictive systems because
the tasks and outcomes are more predictable and do not require
continuous adaptation.

5. What types of projects can use Agile or Adaptive systems?

• Software development projects, such as developing mobile

banking software, are ideal for Agile because they benefit from continuous
feedback and evolving requirements.
 • Research projects like developing a new medicine may
require adaptation due to the inherent uncertainty in the process, but
may face difficulties using a fully Adaptive system.

6. What is the importance of incremental delivery in Agile?

• Incremental delivery in Agile allows teams to deliver small,

usable parts of the product during the project. Each increment is
potentially usable, which enables customer feedback and helps guide
the next iteration.
• For projects where delivering a partially completed product is
impossible (e.g., living in a building without doors or windows), Agile’s
incremental delivery may not be feasible.

7. Can Agile be used in every type of project?

• Agile is not universally applicable. Projects with fixed

requirements and those where iterative development and
incremental delivery are not possible will struggle with Agile.
• However, Agile is suitable for projects where requirements
are uncertain or subject to change, and where the product can be
delivered incrementally.

8. What misconceptions exist about Agile and Waterfall?

• Some people view Agile as a new and revolutionary approach,

while demonizing Waterfall (Predictive systems). However, both
methodologies are valuable when applied to the right types of projects.
Waterfall is still highly effective in projects where requirements are well-
defined upfront, and Agile shines in projects with high uncertainty.

1. Agile Is Not New:

• While Agile became prominent in IT development recently,
Adaptive systems have existed for centuries, even in historical
endeavors such as war. The core principles of adaptation and flexibility
were necessary in many past situations, but Predictive systems became
more popular in the industrial age due to the rise of Taylorism and the
manufacturing mindset.
2. Agile Manifesto’s Four Values:
• Individuals and interactions over processes and tools:
Agile focuses on human elements—the importance of how people work
together—rather than relying heavily on processes or tools. While
processes are important, Agile embeds interactions within the processes,
ensuring that teams prioritize collaboration.
• Working software over comprehensive documentation:
Agile values delivering working increments of a product over exhaustive
upfront documentation. Documentation doesn’t necessarily ensure
understanding; showing and using working software generates clearer
feedback.
 • Customer collaboration over contract negotiation: In
Agile, continuous customer involvement is essential. Contracts are less
rigid, and instead of negotiating changes, Agile promotes regular customer
feedback and collaboration to adjust the product throughout the project.
• Responding to change over following a plan: Agile
emphasizes the ability to adapt to change, accepting that initial plans
may evolve. The focus is on flexibility, responding to feedback, and
shifting priorities as the project progresses, rather than rigidly adhering to
a detailed upfront plan.
3. History of Agile:
• Agile emerged from the limitations experienced in IT
development, where Predictive systems (like Waterfall) often failed to
handle evolving requirements. Agile’s origin lies in methodologies like
XP, Scrum, and DSDM, which focus on adaptation and iteration.
• The Agile Manifesto was created by pioneers of these
systems, focusing on principles that would allow for continuous adjustment
and delivery.
4. Misconceptions About Agile:
• Many people mistakenly believe Agile is just about daily
meetings, collaboration, or self-organized teams. What truly sets
Agile apart is its adaptive lifecycle and iterative delivery, which enable
continuous feedback and product evolution.
Key Questions and Answers:

1. Why is it so critical to have customer collaboration in

Agile?
• Customer collaboration is essential in Agile because the
product is built incrementally, and each iteration requires customer
feedback to inform the next steps. Without regular interaction with the
customer, it’s impossible to refine and adapt the product to meet evolving
needs. Customer feedback during and after each iteration helps guide
future development. Agile projects depend on this feedback to generate
insights, adjust the product, and maintain alignment with customer
expectations. In Predictive systems, most of the customer interaction
occurs at the start and end of the project, but Agile necessitates
continuous collaboration.
2. Why is it easier for us to accept changes in adaptive
projects compared to predictive projects?
• In Adaptive projects (Agile), the lifecycle is designed to
accommodate change naturally. The iterative process allows for
frequent feedback and constant refinement, so changes are expected and
welcomed at each iteration. Incremental delivery provides flexibility to
adjust priorities based on feedback, while in Predictive systems,
changes are harder to integrate due to the rigid upfront plan. Modifying a
detailed plan often requires renegotiating contracts, recalculating
costs, and revisiting earlier work, which can be time-consuming and
expensive. In Agile, the focus is on responding to real-time insights,
whereas Predictive systems aim to minimize changes through careful
upfront planning.
1. What are the two types of Iteration formations?

• Fixed-Duration Iterations and Fixed-Scope Iterations. In

Fixed-Duration Iterations (preferred in Agile), the time is fixed (e.g., 2
or 3 weeks), while the scope can be adjusted. In Fixed-Scope Iterations,
the time is flexible, and the scope is fixed, leading to issues like “feature
creep.”

2. Why is Fixed-Duration Iterations preferred in Agile?

• Fixed-Duration Iterations (or Timeboxing) help prevent adding

unnecessary “fancy” features to items and make the project more
organized by setting predictable timelines (e.g., review meetings every 3
weeks). Fixed-Scope Iterations, on the other hand, can lead to extended
timelines and uncontrolled scope increases, making it harder to maintain
project focus.

3. What is the benefit of having consistent Iteration durations

rather than changing them every Sprint?

• Having consistent Iteration durations reduces the need for

discussions about duration before each Sprint, making planning and
coordination easier. It also allows the customer to anticipate feedback
sessions and review meetings at regular intervals, improving the project’s
rhythm and structure.

4. Can Sprint durations be changed during a project?

• Yes, Sprint durations can be changed during a project if the

team finds it beneficial. For instance, the team may start with one-month
Sprints and later decide to shorten them to three-week Sprints for faster
feedback and adaptation. However, the duration is not decided at the
start of each Sprint; the decision is made collectively during the project if
needed.

5. Why are shorter Sprints often preferred?

• Shorter Sprints enable faster feedback, which is critical in

projects with high uncertainty or risk. However, the duration must be
long enough to complete a meaningful set of features; otherwise, frequent
review meetings with too few deliverables would waste time.

6. What is the risk of having items span multiple Sprints?

• Items spanning multiple Sprints make it harder to deliver

completed, usable features. Each Sprint should aim to deliver features or
items that are fully functional by the end of the Sprint, ensuring
continuous progress and feedback.
7. What are the two alternatives for running Development
Processes within a Sprint?

• Run all Development Processes for all items together:

Analyze all items first, then design all, construct all, etc.
• Run Development Processes for items one-by-one or in
small batches: Complete the process for a feature or small set of
features before moving on to the next.

8. Why is it better to run Development Processes feature by

feature rather than all together?

• Running Development Processes one feature at a time

allows some items to be delivered even if time runs out, enabling feedback
and adaptation. Running them all together risks not completing any items
by the end of the Sprint, making it impossible to deliver, review, or adapt.

9. What is Timeboxing, and why is it important in Agile?

• Timeboxing is the concept of fixing a specific duration for an

Iteration (e.g., two weeks or one month). It is important because it sets
clear deadlines, prevents project delays, and keeps teams focused on
delivering the most valuable features within that fixed time frame. It also
avoids the temptation to extend Iterations to finish incomplete work.

10. What happens if a team doesn’t finish all items in a

Timeboxed Sprint?

• If not all items are completed, the team does not extend the
Sprint. Instead, the incomplete items are either carried over to the next
Sprint or sent back to the Product Backlog for reprioritization. This
ensures the project maintains a predictable pace.

11. Why do some Agile methods like DSDM allow variable Iteration
durations?

• In larger projects with multiple teams, like those using DSDM,

variable Iteration durations might be necessary to accommodate different
project needs. However, in simpler systems like Scrum, consistent
timeboxing is preferred for ease of management.

Conclusion:

The key learning points focus on the advantages of Fixed-Duration

Iterations (timeboxing), the importance of consistent Sprint
durations, and the benefits of delivering features one at a time within
each Sprint. Timeboxing helps maintain a predictable project rhythm, and
shorter Sprints allow for faster feedback and adaptation. Iterative
Development allows for flexibility and continuous delivery, which are core
aspects of Agile project management.
Key Learning Points (in Question and Answer format) based solely
on the transcript:

1. Why is it important to have self-organizing teams in Agile?

• In Agile projects, decisions are made continuously throughout

the project, unlike in Predictive systems where most decisions are made
upfront or at the end. If teams constantly escalate decisions outside the
team, it would block progress. Self-organizing teams are necessary to
empower team members to make important decisions without delays,
ensuring the project runs smoothly and adapts as needed.

2. Why is it important to have cross-functional teams in Agile?

• Cross-functional teams ensure that all the necessary skills

required to deliver a product are present within the team. This eliminates
the need to outsource tasks or wait for external departments, reducing
delays and increasing control over the project. The team has the expertise
to handle every aspect of development, from design to testing, which
accelerates delivery and improves the product quality.

3. How do self-organization and cross-functionality work together

in Agile?

• Self-organization allows team members to take ownership of

the project, while cross-functionality ensures that the team has all the
skills necessary to complete the project without relying on external help.
Together, these traits ensure Agile teams can work independently, make
decisions quickly, and adapt to feedback continuously.

4. Why don’t Agile teams have titles such as “Tester”?

• Titles can create silos of responsibility, where individuals

focus only on specific tasks (e.g., testing) and ignore others. Agile
promotes shared accountability across the team, meaning everyone is
responsible for the overall success of the project. By not assigning titles,
team members are encouraged to contribute in various areas while
maintaining their expertise.

5. Does every individual in a cross-functional team need to be

skilled in everything?

• No, each person brings a set of skills to the team. Cross-

functionality refers to the team as a whole, where each individual
contributes expertise in different areas. Together, the team covers all the
necessary skills to deliver the product. However, over time, many Agile
team members tend to learn a little about different areas of the project,
becoming more versatile.
6. What happens when a team lacks self-organization in Agile
projects?

• Without self-organization, teams would need to escalate

every decision to external stakeholders, which would cause delays and
hinder progress. Agile relies on continuous decision-making, so
empowered teams are critical to maintaining momentum and ensuring
the project adapts efficiently to changes and feedback.

7. What is the relationship between cross-functionality and self-

organization?

• Cross-functionality ensures that the team has the ability to

handle every aspect of product development, while self-organization
gives the team the freedom to make decisions and organize their work.
Both are essential in Agile projects to keep the workflow efficient,
adaptive, and without reliance on external parties for decisions or skills.

8. How do self-organizing and cross-functional teams contribute

to faster adaptation?

• Self-organizing teams make decisions quickly and cross-

functional teams have all the skills needed to execute tasks without
external dependencies. This combination enables faster feedback loops,
quicker adjustments to changes, and ensures that the product evolves in
line with customer needs.

Conclusion:

The key learning points emphasize the importance of self-organizing and

cross-functional teams in Agile. These traits are critical for fast decision-
making, minimizing delays, and ensuring that the team can adapt to
changes quickly. Shared accountability and flexibility in roles allow the
team to work as a cohesive unit, delivering the product more efficiently.

2. Is it alright to have a project manager in a Scrum project?

• No, in Scrum, it is not allowed to have a Project Manager role.

Scrum relies on self-organizing teams where project management
activities are distributed across the team, the Scrum Master, and the
Product Owner. Adding a Project Manager in Scrum would interfere with
this distribution of responsibilities and reduce self-organization and cross-
functionality.

3. What are the project management activities of each Scrum

role?

• Development Team:
• Responsible for estimating the work and determining how
much can be completed within a Sprint.
 • Scrum Master:
• Ensures that the team follows the Scrum process properly.
• Helps resolve problems and conflicts that arise during the
project.
• Product Owner:
• Defines the scope of the project and prioritizes items in the
Product Backlog.
• Measures the progress of the project and ensures that the
team is delivering value according to the stakeholders’ needs.

4. Is it alright to have a PMO (Project Management Office) in a

Scrum project?

• It depends. If the PMO is focused on Program or Portfolio

management (higher levels in the project hierarchy), then it is acceptable.
However, if the PMO is directly involved in the day-to-day management of
the project, it is not allowed, as it interferes with the self-organization of
the Scrum team.

5. What is the difference between a Project, Program, and

Portfolio?

• Project: A project delivers a product—a tangible output such

as a piece of software or a physical product.
• Program: A program is focused on a result rather than a
product. It delivers outcomes like improvements or changes, often
requiring multiple projects to achieve the desired result.
• Portfolio: A portfolio manages the benefits of the
organization, which can include financial benefits, health, safety, or other
strategic goals. It oversees projects and programs to align them with the
organization’s strategic objectives.

6. Why is understanding strategies important in Scrum?

• In Scrum, the Product Owner is responsible for maximizing

value. To do this, the Product Owner must understand what constitutes
value in their organization, which is determined by the company’s
strategies. By aligning project goals with organizational strategies, the
Product Owner ensures that the team delivers valuable results.
Based solely on the transcript, here are the key points to the self-
assessment questions:

1. What are the project management activities of each Scrum

role?

• Development Team: Responsible for estimating the work

needed to complete items in the Product Backlog. They are empowered to
make decisions and self-organize around the work.
 • Scrum Master: Responsible for solving problems, solving
conflicts, and ensuring that the Scrum process is being followed properly.
They serve as a facilitator, ensuring the process runs smoothly.
• Product Owner: Responsible for defining the scope of the
project and measuring progress. They are also responsible for maximizing
value and managing the Product Backlog.

From the transcript:

• “Estimating, that’s a project management activity. Who’s

responsible for estimating? That’s the Development Team.”
• “Solving problems, solving conflicts… that’s a project
management activity. Who’s responsible for that? The Scrum Master.”
• “Defining the scope… and also progress measurement… who’s
responsible for that? The Product Owner.”

2. Is it alright to have a PMO (Project Management Office) in a

Scrum project?

• Yes, but it depends. A PMO is acceptable if it focuses on

Program and Portfolio layers, without interfering with the project’s
autonomy and the self-organization of the Scrum Team. However, if the
PMO directly manages the project itself, this would interfere with Scrum’s
structure, which emphasizes self-organization.

From the transcript:

• “If your PMO is mainly focused on the Program and Portfolio

layers, then it is okay… but if your PMO is directly involved in the Project,
then it is not okay because it’s like reducing the self-organization of the
team.”

3. What is the difference between a Project, Program, and

Portfolio?

• Project: Creates a product that delivers a specific output. For

example, developing software is a project because it results in a tangible
product.
• Program: Focuses on achieving a result, rather than a
product. For instance, improving a document management system is a
program because the goal is the improvement itself, not just a product.
• Portfolio: Manages the benefits of multiple projects and
programs in an organization. It relates to overall organizational objectives
such as financial gains or societal benefits.

From the transcript:

• “The Project is something that creates a product… A Program

is all about a result rather than a product… Portfolio… is about the
benefits you’re generating in your organization through the projects,
programs, and other activities.”

4. Why is understanding strategies important in Scrum?

• Understanding strategies is important in Scrum because the

Product Owner needs to align the work of the Scrum Team with the
broader value and benefit goals of the organization. Strategies define what
is valuable for the company, such as financial gains, health, safety, or
other organizational goals. This enables the Product Owner to make
decisions that maximize value.

From the transcript:

• “You are really focused on maximizing value, but what is

value? It relates to the benefits… And what is the benefit for you in your
company? It all depends on the Strategies.”

1. What are the three pieces of information on a Product

Backlog item?
• The three pieces of information typically found on a Product
Backlog item are:
• Description: What needs to be done.
• Estimate (Size): An estimation of the effort or size required
for the task.
• Value: The contribution of the item to the overall product,
though this is no longer a mandatory attribute in the latest Scrum Guide.
From the transcript:
• “You have the description of what you’re going to do, the
estimate, and the amount of value.”
2. What is a user story?
• A user story is a format used to describe an item from the
perspective of the user, structured as:
• As a [role], I want to [do something], so that [outcome].
• It is used to focus on what the user wants to achieve rather
than technical details.
From the transcript:
• “As a user, I want to do something, so that something
happens.”
3. Is it necessary to use user stories in Scrum?
• No, it is not mandatory to use user stories in Scrum. While it
is a great idea and a common practice, the latest Scrum Guide allows
flexibility in how you document Product Backlog items.
From the transcript:
• “It is NOT mandatory to use User Stories. It’s a great idea to do
so, but you can write it in other ways or do anything you want.”
4. What format is commonly used for Product Backlog
items?
 • Product Backlog items are commonly written on sticky notes
or index cards, often placed on a physical board. While software can be
used, physical boards are encouraged to keep things simple.
From the transcript:
• “We usually create them as sticky notes or index cards and
put them on a real board.”
5. Who is responsible for estimating the items in the
Product Backlog?
• The Development Team is responsible for estimating or
sizing the items in the Product Backlog.
From the transcript:
• “Who estimates the Items? Do you remember? That’s the
Development Team.”
6. What recent updates have been made regarding the
value attribute in Product Backlog items?
• In the latest version of the Scrum Guide, value is no longer a
mandatory attribute for Product Backlog items. The focus has shifted to
thinking about the product as a whole and the relative contribution of
items to value, rather than assigning an absolute value to each item.
From the transcript:
• “The new version of the Scrum Guide has moved away from
that perspective, and the result is that ‘value’ is not one of the mandatory
attributes anymore.”

Specific Answers to Questions:

1. What are the three pieces of information on a Product

Backlog item?
• The three pieces of information are:
1. Description of what needs to be done.
2. Estimate (Size) of effort required.
3. Value (optional in the latest Scrum Guide).
2. What is a user story? Is it necessary to use them?
• A user story is a format used to describe a product feature or
requirement from the perspective of a user, using the structure: “As a
[role], I want to [do something], so that [outcome].”
• It is not necessary to use user stories in Scrum, although it is
highly recommended for simplicity and clarity.

Key Learning Information in Q&A Format

1. What are the two suggested rules for the items in the
Product Backlog?
• The two suggested rules are:
1. Non-Technical: Items should be described in non-technical
terms to ensure they are understandable and presentable to the customer.
This helps in receiving feedback and adapting accordingly.
2. Independent: Items should ideally be independent of each
other so that they can be prioritized solely based on value. This avoids
complications in managing dependencies within the Product Backlog.
 2. Why is it important to follow these two rules?
• Non-Technical: Ensures that items are easily understandable
by stakeholders, allowing better feedback and adaptation.
• Independent: Helps maintain a Product Backlog where items
can be freely ordered based on value, making prioritization simpler and
more efficient.
3. Is it mandatory to follow these rules in Scrum?
• No, it is not mandatory to follow these rules in Scrum. While
these rules are recommended and stem from practices like Extreme
Programming (XP), Scrum does not enforce them to allow flexibility in
implementation.
4. What are non-functional features?
• Non-functional features are characteristics of a system that
describe how the functions of the software should operate rather than
what the software does. Examples include security, scalability, and
maintainability. They often influence other functional features rather than
existing as standalone functionalities.
5. How do we handle non-functional features in Scrum?
• Non-functional features can be handled in several ways in
Scrum:
• They can be incorporated into the Definition of Done,
applying them as standards across all items.
• Alternatively, they can be added directly to the Product
Backlog, especially if they are measurable and presentable (e.g., “search
results must be delivered in 0.1 seconds”). Scrum allows flexibility in
handling non-functional features.

Answers to Self-Assessment Questions:

1. What are the two suggested rules for the items in the
Product Backlog?
• The two suggested rules are that items should be non-
technical and independent.
2. Why is it important to follow these two rules?
• It is important because:
• Keeping items non-technical ensures they are
understandable and presentable to stakeholders, aiding feedback and
adaptation.
• Making items independent simplifies prioritization and helps
manage the Product Backlog based solely on value.
3. Is it mandatory to follow them in Scrum?
• No, following these rules is not mandatory in Scrum. These
practices are suggested, particularly in XP, but Scrum has made these
optional to provide flexibility in implementation.
4. What are non-functional features?
• Non-functional features describe how a system should
perform certain functions (e.g., security, performance standards) rather
than describing what the system does.
5. How do we handle non-functional features in Scrum?
• Non-functional features can be:
 • Added to the Definition of Done if they are applicable across
the software.
• Included in the Product Backlog if they are presentable, non-
technical, and measurable.

1. What are the two types of elements in the Sprint Backlog?

• The two types of elements in the Sprint Backlog are:
1. Items: These are picked from the Product Backlog.
2. Tasks: These are created by breaking down the items into
smaller, actionable components.
2. Can changes be made to the Sprint Backlog during the
Sprint?
• Yes, changes can be made to the Sprint Backlog during the
Sprint. Tasks are created gradually, and therefore, the Sprint Backlog is
always evolving throughout the Sprint. However, changes to the items
themselves can be more controversial, and opinions vary on this matter.
3. What is the traditional view on changing items in the
Sprint Backlog?
• The traditional view is that once the Sprint Planning is
complete, the items in the Sprint Backlog are “frozen” for the duration of
the Sprint. This approach is taken to create a stable and predictable
environment for the developers.
4. What is [Link]’s stance on changing items in the
Sprint Backlog?
• [Link] takes a more flexible approach, allowing changes to
be made to the Sprint Backlog items during the Sprint. This allows for
more adaptability but may compromise the stability of the environment.
5. Who can cancel a Sprint, and under what
circumstances?
• The Product Owner is the only person who can cancel a
Sprint. This happens when the Sprint Goal becomes obsolete or the entire
Sprint Backlog no longer makes sense due to significant changes (e.g.,
new regulations or priority shifts).
6. What happens when a Sprint is canceled?
• If a Sprint is canceled:
• Any completed items can be turned into an increment and
reviewed.
• Unfinished items return to the Product Backlog for refinement
and reprioritization.
7. Is it acceptable to make changes in the middle of a
Sprint that could affect the Sprint Goal?
• No, changes that might endanger the Sprint Goal should not
be made during the Sprint. Examples of such changes include:
• Modifying the Definition of Done
• Lowering quality standards
• Changing the Sprint Goal itself (though refining it is
acceptable)
• Changing the team composition

Answers to Self-Assessment Questions:

 1. What are the two suggested rules for the items in the
Product Backlog? Why is it important to follow these two rules? Is
it mandatory to follow them in Scrum?
• The two suggested rules are:
• Items should be Non-Technical: To ensure clarity and enable
feedback.
• Items should be Independent: To simplify prioritization and
avoid dependency management.
• It is important to follow these rules to create an adaptable and
efficient backlog. However, these rules are not mandatory in Scrum.
2. What are non-functional features? How do we handle
them in Scrum?
• Non-functional features describe the qualities of the system
(e.g., security, performance). They can be added to the Product Backlog if
they are measurable and presentable, or included in the Definition of
Done if they apply broadly to the project.
3. What are the project management activities of each
Scrum role?
• Development Team: Responsible for estimating items and
completing the tasks.
• Scrum Master: Ensures adherence to the Scrum process,
resolves conflicts, and supports the team’s productivity.
• Product Owner: Defines the scope and prioritizes the
backlog, monitors progress, and decides on the value.
4. Is it alright to have a PMO (Project Management Office)
in a Scrum project?
• It depends. A PMO is acceptable if it focuses on the Program
and Portfolio layers, as this does not interfere with the Scrum team’s
self-organization. However, if the PMO directly influences the project, it is
not compatible with Scrum’s principles.
5. What is the difference between a Project, Program, and
Portfolio?
• Project: Focuses on delivering a specific product or output.
• Program: Involves achieving a result that may require
multiple projects to deliver the outcome.
• Portfolio: Manages benefits across projects and programs,
aligning them with organizational strategies.
6. Why is understanding strategies important in Scrum?
• Understanding strategies is important because it helps the
Product Owner maximize value by aligning the Product Backlog and the
product’s development with the organization’s broader goals and benefits.

Lesson 22: Readiness

 00:05 – Let’s talk about the size of items.
 00:09 – There are many people who say that the items that we have
in the Product Backlog have to be small.
 00:18 – This is the case, but only for the items on the top of the
Product Backlog, not all of them.
 00:26 – This is how it works. Let’s say you’re the Product Owner and
you start creating items.
 00:33 – In the beginning, you don’t go through all the details.
 00:37 – You just capture high-level ideas and create really, really big
items for your Product Backlog, and then when you go on, you will
order the items and some of them will be on the top of the Product
Backlog, and then you see that, those big items are not clear
enough.
 00:57 – Items are made clear when they are smaller.
 01:02 – So, when something is on top of the Product Backlog, you
know that it will be developed sooner, so you have to make them
clear.
 01:10 – In other words, you have to break then down into smaller
items.
 01:15 – And then you will go down a little bit because those items in
the middle will be developed soon, not immediately, but soon, but
you don’t have to make them as small as the items on the top of the
Product Backlog.
 01:30 – You will do all of that and then you will order them again.
 01:34 – Some of those items that you had on the top broken down
will go down because for each feature, for each function or each part
of the product, we can have really important features and also fancy
features.
 01:51 – When you have big items, all of them are together in one
big item, but when you break them down, you have the option to
leave some of them to the bottom of the Product Backlog, which is
great, which means that you will create the most important part of
the system, something that people need most and they will use
most of the time, but the fancy features will be at the end.
 02:19 – You may do them or you may not do them. That’s up to you
and the customer.
 02:24 – So, basically what happens is that in a normal Product
Backlog, we usually expect to have smaller items on the top and
bigger items on the bottom.
 02:37 – Be very careful with this. It doesn’t mean that we sort the
Product Backlog based on size.
 02:43 – It’s because of the way we work.
 02:46 – When something is on the top of the Product Backlog, we
will make it smaller, not that because it’s smaller, we will put it on
the top.
 02:54 – I know that it may be so easy and you may be wondering
why am I explaining it so much, but I know that some people make
mistakes here.
 03:03 – So, that is about the size and there are a few names
common in the Agile community.
 03:10 – On the top, we have normal items and if you decide to use
User Stories, then you will have normal User Stories.
 03:20 – In the middle, you will have normal User Stories and big
User Stories, and a common name for those big User Stories is Epic
 User Stories, and then in the bottom, in addition to those two, you
will also have Themes.
 03:37 – A Theme is a really huge part of your product.
 03:42 – For example, let’s say you’re working on a website, if you
have an item as CRM, Customer Relationship Management, then it is
absolutely huge.
 03:53 – That is a Theme, and this is one way of describing or
defining a Theme.
 03:59 – The other thing is to use it for categorizing the small items.
 04:05 – So, different people use it in different ways.
 04:08 – For your exam, for [Link], you don’t really need this
terminology.
 04:16 – They belong to other communities, other Agile communities,
but you still need to know what they are about, okay?
 04:25 – So, in general, smaller on the top, bigger on the bottom.
 04:31 – Now, tell me, the average size of the items on the Sprint
Backlog, is it bigger or smaller than the average size of items in the
Product Backlog?
 04:47 – What you have in the Sprint Backlog comes from the top of
the Product Backlog, and things are smaller in the top … on the top
of the Product Backlog.
 04:55 – Therefore, the average size in the Sprint Backlog is smaller
than the average size in the Product Backlog. Alright.
 05:03 – So, we have the size and the opposite is accuracy.
 05:09 – The items that are on the top and are smaller are more
accurate or they are clearer than those on the bottom.
 05:18 – Now, you remember that the main reason that we break
down the items and make them smaller on the top of the Product
Backlog is that we want them to be ready for development.
 05:31 – We want them to be clear.
 05:35 – So, for example, if an item is so large that you cannot fit it
in one Sprint, that is not okay because we want to finish something
in one Sprint or at least have the potential to finish that. Okay. So,
that’s one of the things.
 05:52 – The other thing is that you need to have a clear idea of
what that item means.
 05:58 – You should be able to explain it to your developers.
 06:01 – If, for example, the only idea is that you have is that we
need to have some form of Customer Relationship Management,
then it is not enough. You need to know the scope of Customer
Relationship Management, the types of features that you want to
have there, and that brings us to the idea of having ready items on
the top of the Product Backlog.
 06:26 – We really want those items to be ready, and those are the
items that the developers will pick for the Sprint Backlog, and by
being ready, it means that they need to be small enough, they need
to be clear, maybe in some cases, you also want to have some
acceptance criteria for that and so on.
 06:50 – Now, what happens if you have an item on the top of the
Product Backlog and it is not ready?
 06:58 – What would you do?
 07:04 – Some people may say that you will just leave it there and
you will pick the next items.
 07:10 – That is not okay because we really want to go based on the
order of items here, based on their value. We don’t want to skip any
items.
 07:20 – So, if something is on the top of the Product Backlog and it
is not ready, we will still pick it for the Sprint Backlog and it’s fine.
 07:29 – During the Sprint, the developers will come back to you, the
Product Owner, you will work on that, and you will refine the item.
 07:39 – You will make it ready during the Sprint. That’s what we do
in Scrum, and that is why [Link] is against the idea of having a
Definition of Ready.
 07:52 – There are some people who create this concept of Definition
of Ready, which describes when something is ready, and [Link]
is against that because they believe that if you have such a
definition, it makes it official for those items and it forces everyone
to make things ready before the Sprint Planning, and if things are
not ready, then they may skip that one and go to the next items.
 08:21 – So, because of that, we don’t have a Definition of Ready,
but we still have the concept of Readiness. Okay?
 08:29 – Alright. The next item, the next topic that we’re going to
talk about in the next lesson is the size of items. It’s about
estimating.

 Lesson 23: Story Points

 00:05 – We talked about the nature of items that you have in
the Product Backlog, and then started talking about the size of
those items.
 00:13 – Continuing the next the same topic, now it’s a good
idea to think about the units of measurement.
 00:20 – Basically, according to [Link], you’re free to use
any unit of measurement that you want.
 00:28 – Like many other things, you’re not constrained, but
generally speaking, in the Agile community, it’s a really
popular thing to use effort-driven units instead of time-driven
units such as Man-Days.
 00:45 – The reason is that if you use a unit like man-days and
say that, for example, this thing is 40 man-days and then
people can calculate the amount of man-days that you have
during the Sprint or any other partition of time, and if they don’t
match, they may blame you, and it’s a really bad thing
because if the developers see that they are being blamed for
 their performance, then they keep adding margins to the
estimates, and when they have margins in each and every
estimate, then it’s very difficult to manage them and they will
have a lower productivity.
 01:27 – It’s the Parkinson Law. Work expands to fill in the
available time.
 01:33 – So, if you believe that something is 40 man-days and
then you say that it’s 50 because you want to be safe, then
there is a tendency for you to expand it to 50 days
unconsciously, and that’s a bad thing, that’s why we don’t want
it.
 01:51 – That’s why the time-driven units are not the best way
we can do it, and we have this option of effort-based units, and
there are two main effort-based units.
 02:02 – One of them is a Story Point, which is a more popular
one, and the other is Ideal Time, which I won’t mention here
because the Story Point is famous, and nevertheless, you
don’t have any questions about that in your exam.
 02:17 – So, even though you’re not going to have questions
about Story Points, I’m going to tell you what it is because it’s
absolutely useful for you in the exam in your work.
 02:28 – So, that’s how it works. We pick a reference.
 02:33 – One user story, or anything else, and you consider it
as the definition for 1 Story Point, and then whenever you want
to estimate another user story, you will compare it with the
reference and see if it’s bigger or smaller than the reference
based on the amount of effort that you need to put in to
developing that thing, and it includes the scope of that item,
the complexities that you have, the risks that you have, all of
that, and when you do it, you can say that, okay, for example,
it’s 6 times larger.
 03:14 – In that case, it will be 6 Story Points. If you think that
it’s …
 03:19 – it takes, the size of your target user story is half the
size of the reference user story, that makes it half a Story
Point. That is the concept of Story Points.
 03:31 – It’s a relative, effort-based units of … unit of
measurement.
 03:37 – Now, you may be thinking that it can be translated into
time. It is not different from time.
 03:45 – It can be translated, but it is not the same as time.
 03:50 – I know that what many people do is that they have an
idea of the duration that it takes to complete 1 Story Point user
story.
 04:01 – For example, they don’t … they know that it takes 1
day, and then whenever they want to estimate something else,
they say that, okay, I think that it takes 3 days. Alright. That
makes it 3 Story Points.
 04:14 – That’s not okay. That’s wrong, absolutely wrong.
 04:17 – I will tell you more about the relationship by doing this
practice.
 04:22 – Let’s say it’s been 90 days in your project, okay? Don’t
think about the Sprints for now. 90 days.
 04:32 – And during these 90 days, you’ve completed a
number of user stories worth of 175 Story Points.
 04:42 – Now, can you tell me your average output?
 04:48 – That’s really simple. You just divide them, and the
answer is that on average, you’re developing about 2 Story
Points per day. Okay?
 05:01 – Now, if you have 1 user story that is estimated to be 6
Story Points, can you tell me how long it takes you to develop
that?
 05:14 – We divide 6 Story Points by 2 Story Points per day
and the result is 3 days. That’s how it works.
 05:22 – That is the relationship between Story Points and
time, and it is based on statistical information, it’s not a fixed
number. Let’s see.
 05:35 – You go on with your project and let’s say after 140
days, you have completed a number of items that are equal to
625 Story Points or something like that.
 05:47 – Now, what’s your average output? You divide them
and let’s say the answer is 3 Story Points per day.
 05:55 – Now, how long it takes you to finish a 6-Story Point
user story?
 06:03 – The same thing, it takes 2 days here.
 06:07 – What happens here is that in the beginning of the
project, you don’t have all the information about the project.
 06:16 – You don’t know your environment very well.
 06:19 – When you go on with the project, it becomes probably
easier for you to work with your customer, to work with other
environmental factors, and then as a result, you can be faster.
 06:33 – The same user story that could take you about 2 days
to develop …
 06:39 – 3 days to develop in the beginning of the project can
take you 2 days to develop after a while, that’s natural, and the
great thing here is that this concept is reflected here without
you needing to re-estimate everything. The item stays as 6
Story Points, but it’s interpretation to time will be different, and
that’s the concept of Self-Correction that we have when we
use the effort-based units.
 07:12 – Now, this Self-Correction is all based on the average
that we calculate.
 07:15 – That is important for us. You can use it to do
forecasts.
 07:20 – You can even forecast the completion date of the
project using that, and you remember that the completion date
of the project is calculated by the Product Owner.
 07:31 – So, this is our average output. This is our speed and
because it’s important, we have a relatively special word for it.
Velocity.
 07:45 – That’s what people mean by Velocity. It shows our
speed.
 07:51 – It is our average output in each duration. For example,
it can be Story Points per Sprint or anything else, any unit of
size that you have. Ideal man hours per day, per anything.
That is Velocity.
 08:09 – Now, to make sure that you know how it is done,
maybe we can have this little exercise here.
 08:16 – At the end of your first Sprint, these are the items that
you had in your Sprint Backlog, their size based on Story
Points, and the progress.
 08:28 – Can you tell me what your Velocity is here?
 08:34 – Alright. The first thing that you have to do is that in
Agile, we don’t have percent completes like that.
 08:43 – Anything is either done or not done, and if it is not
done, it doesn’t matter what the progress is, we won’t calculate
it because it’s not reliable and you know how long it takes to
finish a 90% or a 95% done item.
 09:04 – So, your first step is to remove everything that is not
100% done, and how do we know if something is done? Based
on the Definition of Done.
 09:15 – Alright. So, we do that first and then it’s very easy. We
just sum up those items and it was for 1 Sprint, and therefore
our Velocity will be 44 Story Points per Sprint.
 09:29 – Now, if it happened during 2 Sprints, if that was the
output for your 2 Sprints, then all you have to do is the same
thing, but instead of dividing that by 1, you will divide it by 2,
and your Velocity will be 22 Story Points per Sprint. Okay.
 09:49 – You can track your Velocity if you want. That may be
helpful, and if you draw it, first of all, you will see something
like this.
 10:03 – In the beginning, it’s not as much as the rest of the
project, and that is mainly because we are spending some of
our effort on preparing, preparing the infrastructure, everything
that we need to develop. That is also part of our work, so not
all of our capacity is spent on developing the real items, and
also for that part of the capacity, we still have to get to know
each other as developers and get to know the customer.
These all take time.
 10:36 – So, our output, our average output, which is the
Velocity, will be lower in the beginning, and after that, we really
like to have a little bit of improvement every Sprint.
 10:50 – You remember, we have the Sprint Retrospective
where we sit down, we think about everything that has
happened, and try to find a way to improve things for the next
Sprint.
 11:02 – The … one of the important things is that for many
people, velocity is the main measure of success for the
developers.
 11:15 – That is not true. Can you say why?
 11:21 – It is not a correct measure of success because
velocity is only about speed and it doesn’t tell you in which
direction you’re moving.
 11:32 – Our main goal here is to satisfy the end-users and the
customer, and that satisfaction will be reflected in the value
that is generated or can be generated by the product, and
none of these have a direct relationship with your speed.
 11:54 – That’s why Velocity by itself is not a good measure. It
is not our goal to increase velocity.
 12:03 – Our goal is to increase value. Okay? That’s very
important.
 12:08 – The other misconception that we have is to compare
velocity of two different teams or two different projects.
 12:17 – It is also wrong. Can you say why?
 12:22 – First of all, velocity is not a measure of success.
 12:27 – Secondly, they may have different number of
developers, they may have developers with different levels of
expertise, they may be working on items with different levels of
difficulty, and if they are using Story Points, then the Story
Points are based on relative units.
 12:47 – They are based on the reference that you select in
your project, and not every project has the same reference.
 12:53 – Therefore, you should not compare velocities of two
different teams or two different projects.
 13:01 – Okay. So, that was it about the units of measure. To
recap, for your exam, in [Link], remember that you don’t
have to use Story Points or any other specific unit.
 13:15 – You can use any unit, but in general, for your work, it’s
a great idea to use Story Points.
 13:22 – Now, in the next lesson, we’ll see how estimation is
done in a Scrum project.

 Lesson 24: Planning Poker

 00:05 – Once again, what are the three pieces of information
that we have for every Product Backlog item?
 00:12 – The description of the work, the estimate, and the
value.
 00:18 – We talked about the description of the work, and now
we are still thinking about the estimation.
 00:25 – In the previous lessons, we talked about the size of
items and the units of measurement.
 00:32 – And now it doesn’t matter what unit you are using,
when it is time to estimate, which is done during Product
Backlog refinement, you go to the developers, you explain
what the item is about and then ask them to estimate, and you
 know that it’s only the developers who estimate the size of
items.
 00:54 – Now, the problem is how are you going to estimate as
the developers?
 01:01 – One very simple way of doing that is when they are
ready, they can start giving their opinions.
 01:08 – People start from one side and go on. For example, if
you’re using Story Points, people can say, “I believe it’s 2
Story Points, 3 Story Points,” and so on.
 01:19 – The problem here is that let’s say you’re one of those
developers, and you’re thinking that this item may take 5 to 10
Story Points.
 01:29 – You’re still wondering, you’re not sure, and people
start talking, “2 Story Points, 3 Story Points,” and then chances
are high that you will say 5 Story Points to be closer to those
people, and that is the case while if the same people start
telling 12 Story Points or 15 Story Points and so on, you as the
same person who have been thinking about 5 to 10, now may
say 10 Story Points.
 02:03 – And the problem is that when you do it like this, then
the first one or two people who are giving their ideas will bias
everyone else.
 02:12 – They will anchor the whole estimation. Therefore, you
will lose accuracy and reliability of that data.
 02:23 – To avoid this bias, one of the most common things is
that people will have numbers on cards, and when they are
ready to vote, instead of shouting, they will pick one of the
cards, they keep it face down, and when everyone is ready,
then they will show their cards.
 02:45 – As you see here, people are not biased anymore and
that’s a great thing, and this is called Planning Poker.
 02:54 – What you see here is a normal set of cards. It’s a
simplified Fibonacci series here that we have and that’s
because the differences between different values are not
significant.
 03:09 – For example, the difference between 2 and 3 is
significant. We can understand this difference, but we cannot
understand the difference between 40 and 41.
 03:19 – That’s why we don’t have 41, and it jumps from 40 to
100, but it’s up to you. If you want, you can use another set of
 cards, it’s absolutely fine, and there are even some people
who use T-shirt sizes.
 03:32 – You consider a certain number for each of those
sizes, but when you are estimating, you will use T-shirt sizes,
and this is so because when people are new to using relative
units, the Story Points, they keep think of them … keep
thinking of them as time.
 03:52 – They cannot think of them as absolute values for size.
 03:57 – In that case, the Scrum Master may suggest using T-
shirt sizes to let them get used to this type of estimation, and
then later on, you will convert those T-shirt sizes to numbers.
 04:12 – One more thing about the Planning Poker type of
estimation is that when you have the initial ideas, when you
have the numbers, you will check them to see if they are
almost in the same range.
 04:26 – If they are really different, it means that some of those
people don’t have a correct idea of the item.
 04:34 – In that case, we will discuss them again and vote
again, and when you finally have numbers in the same range,
people have different opinions on how to turn that into one
number.
 04:52 – Some people just pick something in the middle, some
people just calculate the average, I would calculate the
average, I think that’s the best way, and there are even some
people out there who pick the maximum, and they are usually
the conservative people who believe that when people pick a
number of items for the Sprint, they must really deliver
everything.
 05:17 – So, here we will pick the maximum to make sure that
everyone is comfortable with every number, and that is not
really a good idea because when you’re picking the maximum,
you’re ignoring every other input and that is not correct, while
when you’re calculating an average, you’re considering all
those data, all the inputs from every developer, you’re not
ignoring anything, and then later on, when we have the
Velocity and we have the Self-Correction, you will have a more
reliable Self-Correction in your project.
 05:52 – Okay. So, I think that’s enough for estimation.
 05:57 – So, from those three items, we have the description
covered, we have the estimation covered, and now we have
the most difficult one, Value.

 Lesson 25: What's value?

 00:05 – Okay. We talked about the type of works that we
create here, the types of items that we create in the Product
Backlog and then about the size of those items and the way
we estimate the size.
 00:18 – Now in this lesson, we’re going to talk about Value,
which is we talk …
 00:23 – we keep talking about it all the time. In Agile, we are
always focused on maximizing value, but what do we mean by
value?
 00:32 – And in most resources, we don’t have enough
explanation about value. That is a big problem, I would say.
 00:41 – So, here I’m not going to go through all the possible
details.
 00:46 – I’m going to maybe you can say more encourage you
to go and study more about value.
 00:53 – There is, for example, this great resource called MoV,
Management of Value.
 00:58 – It’s a standard or a certification programs for it and it’s
all about value, and it applies to Predictive projects as well as
Adaptive projects, even programs and portfolios.
 01:11 – That is really great for Product Owners. But now just a
little bit and the whole lesson may be a little bit abstract, so
just stay there.
 01:25 – Alright. So, as I told you before, what we can say
about order in the Product Backlog is that we order them
based on the value of the items.
 01:36 – If the item has a higher value, it will go higher in the
Product Backlog.
 01:41 – That is not the perfect way of describing that.
 01:47 – This is the way we used to describe it for a really long
time, but nowadays most people are moving towards that
second definition, where we say that we will order the items in
a way that they maximize the value of the product.
 02:03 – Do you see the difference here?
 02:06 – The difference here is that in the second definition, we
consider value as something that can be evaluated in the
product, not for isolated items, and that is true actually
because think about the different features that you have in a
piece of software.
 02:23 – The amount of value that they generate depends on
other features that you have.
 02:30 – Sometimes other features make the target feature
more interesting, more useful, more attractive, and therefore,
the same feature will generate more benefits, and that extra
benefit is something that is absolutely non-linear, you cannot
really assign it to any single feature.
 02:50 – So, in practice, we really don’t know the amount of
value of each item.
 02:57 – That depends on everything else, on every item that
we already have in the piece of software, and everything that
we may have in the future. That makes it almost impossible to
use the first one.
 03:11 – Well, we can still use it but maybe it’s not reliable
enough, it’s not considering every possibility, but for the
second one, that’s very realistic, that’s more correct, but it’s
not as straightforward as the first one.
 03:29 – Now, regardless of that, when we say value and we
keep saying value all the time, what do we mean by that?
Based on what I hear and read, I would say that everyone who
is talking about value is considering either of those two
definitions.
 03:51 – They consider it as the benefits or the ratio between
the benefits and cost.
 03:58 – The second one, for example, is a more serious type
of definition, more advanced if you will, and if you go to the
MoV standard, then that second one is what they consider
value, but for the first one, that’s what we have in the day-to-
day language, I think.
 04:17 – For example, if someone says that this thing is really
great value for money.
 04:22 – Value divided by money. That cannot be benefits to
cost to cost, it’s probably benefits to cost.
 04:31 – So, what they consider for value is the first one. That’s
why they say “value for money.” And in Agile, in the Agile
 community, in most cases, when they are talking about value,
they consider the first one, the day-to-day language, but the
way they use value in the whole system, at least sometimes, it
implies the second one or I can say it’s better to consider the
second one if we really want to be successful in Agile based
on everything that we say about value.
 05:07 – Just let’s have a really quick example here.
 05:11 – Think about two different features and forget about the
combination of different features here in a really ideal world.
 05:20 – The first feature generates … can generate about
10,000 Euros, that’s the benefit, and the second one
generates, for example, 15,000 Euros.
 05:31 – Which one is better? Which one has more value?
 05:36 – If you take the first definition, then you may say the
second one has more value, but the problem here is that this
amount of information is not enough for us to decide because
what if the first item takes us 1000 Euros to develop and the
second one takes us 20,000 Euros to develop.
 06:00 – In that case, the first item is much better than the
second one, and it has more value if you take the second
definition. That’s why I prefer the second definition.
 06:12 – That makes more sense when we use the word Value.
 06:17 – The second item, I’m not comfortable using the word
Value for the second item, you know what I mean.
 06:27 – Alright. So, that was it. Now, we can go into a lot of
detail and consider four combinations of the two definitions of
Value and two approaches into ordering the Product Backlog.
 06:44 – One of these really doesn’t work? Which one is it?
 06:49 – That’s the first one. When we consider the first
definition of Value, which is only the benefit, and then we say
that we will order the items based on the benefit that they can
generate.
 07:00 – That really doesn’t make sense because we also have
to consider their cost, at least.
 07:07 – And for the other ones, well, I would say the best one
is that.
 07:12 – To use the second approach in ordering and use it
with the second definition of Value, but anyway, in … in your
exam, what [Link] considers, they are more towards the
 first definition of Value and that’s why recently, it wasn’t like
that before the …
 07:33 – in the past, they used to simply say that we will order
them based on value, but nowadays they are moving towards
saying that we order the item based … items based on their
value, their cost, their dependencies, their risk, and everything
else that is important.
 07:50 – And there’s a lot to talk about here.
 07:54 – First, they have to consider Cost separately because
what they have in mind for value is only about the benefits.
 08:03 – Then Dependencies because they don’t force
themselves to create independent items.
 08:10 – Do you remember those two characteristics that I told
you, that is the old-fashioned way of creating the items?
 08:17 – They must be non-technical and they must be
independent of each other, but these two are not forced in
[Link] in your exam.
 08:25 – So, that’s why we have dependencies, and then Risk.
 08:29 – We don’t really have to consider risk separately
because if you consider risk properly, then it will affect your
benefits and your cost.
 08:39 – So, as long as you calculate your benefits and cost
correctly, you have considered risks as well.
 08:49 – You don’t have to do it again. But anyway, that was
just a few things that you need to be aware of, I would say, but
if you’re interested, there’s a lot of great resources to read
about Value.
 09:01 – So, we have the items and, as you remember, we
have those three pieces of information, and one interesting
thing is that we still have that third item there, the Value.
 09:16 – It’s there from the old days where people used to say
that we will order the items based on their value.
 09:23 – Nowadays, [Link] and many other resources are
moving towards the second approach to ordering, which is
about maximizing the value of the product instead of thinking
about the value of items, but still we have it there. Maybe they
will remove it in the future. I don’t know.
 09:42 – Alright. So, the other thing that you may see
sometimes is that for people who are still considering value for
 individual items, they still need to calculate value somehow,
and it’s very, very difficult to come up with calculations.
 10:01 – So, practically most people just do it intuitively, all the
Product Owners, and sometimes they have tricks for that. For
example, they still use intuition, but they incorporate the
opinions of more people.
 10:15 – They bring a number of people and they ask them
about their opinions about value, and when you do it, you
remember when we wanted to estimate the size and we had
that problem with anchoring? What was the solution? Planning
Poker.
 10:31 – So, some people use something they call Value
Points, and they use something similar to Planning Poker. So,
people have some cards with some values there.
 10:43 – They will prepare it, they will discuss it, and then they
distribute the points, it’s a limited number of points, to
everything that you have in the Product Backlog.
 10:54 – So, that makes it a relative evaluation of the value of
products, and as usual, it’s not mandatory to do in Scrum
based on [Link], and even I’m not sure if it’s the best way
of doing that, but that’s another topic.
 11:14 – So, before I finish this lesson, there’s one more thing
to tell you.
 11:19 – I know that this one, this one lesson is longer than
every other lesson.
 11:24 – What you’re talking about here is about Ordering the
items, which is different from Prioritizing the items.
 11:34 – Do you know the difference? Ordering is about just
having an order.
 11:39 – This one, then this one, then this one, then this one,
and so on. That’s ordering, but prioritizing is about putting
those items into different categories.
 11:49 – For example, very important, important, moderately
important, not important, nonsense, anything you want.
 11:56 – That is prioritization, which is different from ordering.
 12:00 – What you must do as a Product Owner is to order the
items.
 12:05 – If you want, if you believe that it can help, then you
can also prioritize the items.
 12:14 – And if you want to prioritize the items, one really good
way is to use MoSCoW prioritization.
 12:21 – Do you know that? It comes from DSDM, the other
Agile methodology, and in MoSCoW prioritization, M, S, C,
and W stand for Must-Have, Should-Have, Could-Have, and
Won’t-Have.
 12:35 – The Won’t-Have is simple, I won’t explain it, but the
Must-Have is something that if you don’t have in your product,
then you’re not allowed to use the product. It’s illegal, for
example, or it’s really stupid.
 12:47 – For example, if you take a word processor that cannot
edit text, then it’s really silly.
 12:54 – So, you can call it a Must-Have, or if you have a car
without side mirrors, then this is against the law, so we cannot
use it. That makes it a Must-Have.
 13:05 – Now, for the Should-Haves, if you don’t have it have
them in your product, you will have problems, but you can
have workarounds.
 13:15 – You can do it manually or you can use another piece
of software in parallel.
 13:20 – For example, for me, if my word processor doesn’t
have the feature to, I don’t know, for example, merge … merge
external information, in some cases, I will have problems, but I
can just write everything manually with my hand.
 13:40 – It will be very difficult, but it doesn’t block me, I can still
go on.
 13:46 – And Could-Have is something that can add value, but
it doesn’t create a problem if you don’t have it.
 13:53 – Now, what happens is that if you use MoSCoW
prioritization based on the way it is defined, then you can think
of different partitions in your Product Backlog.
 14:06 – You will naturally start with Must-Haves and then go
through Should-Haves, and then go through Could-Haves, but
still inside those different groups, you have to order the items.
 14:17 – And the other terms that you may hear in the
community are MUST, MVP, MMP, and all those things.
 14:27 – MUST stands for Minimum Usable Subset, and that’s
the set of all Must-Have items because that’s a minimum that
you must have if you want to use the software obviously based
on the definition.
 14:45 – MVP is the Minimum Viable Product and based on the
different ways that people define it, it can be smaller than
MUST or it can be even the same size as your MUST. No one
knows.
 14:57 – And MMP is the Minimum Marketable Product, and
again it can be the same size as the MUST or maybe you can
have a little more items, a few Should-Have items.
 15:13 – You may say that if I go to the market without some of
my Should-Haves, it won’t be attractive enough for people. In
that case, that’s what you would do.
 15:23 – Alright. That was long. So, it was about Value.
 15:29 – I hope you are interested in learning more about
Value.
 15:33 – Now, in the next lessons, we will have easier, more
simpler ideas to discover together.

 Lesson 26: Visualizing

 00:05 – Alright. What do you see here? In this board?
 00:13 – We have the Sprint Backlog, which is the right side of
the board where we have the items from the Product Backlog
and the tasks, and then on the left-hand side of the board,
we’ve added the Sprint Goal because that can be a good idea.
 00:28 – If you want, you can also add your Definition of Done,
and on the bottom left, we have the Progress Information, and
in this case, when it is about the Sprint and that’s the progress
of our Sprint, who do you think should be responsible for
calculating the progress of the Sprint?
 00:48 – That’s the developers because they know best what’s
happening inside the Sprint, and yet that is not enough to only
calculate our progress during the Sprint.
 01:02 – We also need to consider the progress of the whole
project and know where we are, where we are going, and
when we are going to finish the project.
 01:12 – Who do you think should be responsible for
calculating the progress of the project?
 01:16 – That’s the Product Owner because the Product Owner
is the one who knows best about the whole project and what’s
happening in the Product Backlog.
 01:27 – Developers are those who know best what’s
happening inside the Sprints.
 01:34 – It’s up to you to decide how you want to measure
progress.
 01:37 – There are different ways, but the important thing is to
consider the principle.
 01:42 – Do you remember the principle that was about
progress?
 01:45 – Our main measure is the working software, not
something else such as man hours or lines of codes and that
type of thing.
 01:54 – So, the way you measure progress should be aligned
with the working software, with the amount of value that we
are generating.
 02:04 – Now, different ways of doing that are indirectly about
the scope, and what we do, most people do in the Agile
community, is that they create Burn-Down charts, which look
like this. It’s about … it shows the amount of remaining work
across time.
 02:23 – So, when you work and get things done, it goes down
just like that and, for example, if you want, maybe you have a
deadline for your project, for example, then you can draw a
line, and in that case, in this example, are we ahead of
schedule or behind schedule?
 02:47 – You’re ahead of schedule because we’ve got more
things done and we have less remaining work.
 02:56 – That’s the opposite of how progress is usually shown.
It usually goes up.
 03:02 – So, how about here? In this example, we are behind
schedule because it’s higher.
 03:09 – We have more remaining work than we need to have
if we want to meet the deadline.
 03:16 – And this whole calculation can be based, can be for
one single Sprint or for the whole project.
 03:25 – If it’s for a Sprint, then you will have the number of
days, and if it’s going to be for the whole project, then you will
probably have the number of Sprints.
 03:34 – The other thing is that we can also draw a trend line
here, and what would it show?
 03:39 – It will show a simple forecast for the completion date,
but this is based on a huge assumption.
 03:47 – What is the assumption here? If we say that this is our
forecast for the completion date?
 03:53 – That assumption is that the amount of work in the
Product Backlog won’t change a lot.
 04:00 – If you suddenly add a lot of new things to your Product
Backlog, then this trend line won’t work obviously.
 04:07 – And how do you want to show it on your diagram?
 04:10 – One way is to add it to the bottom of the diagram
because you don’t want to update everything on the top, and
even if you want, you can draw a second line that shows the
amount of things that you have defined in your Product
Backlog, but these are all optional, you know, it’s not rocket
science, it’s not important.
 04:32 – It’s just your decision on how to visualize the
information.
 04:37 – It’s not the measurement itself, it’s the presentation of
the measurement, even though in many resources, they
consider these as the measurements themselves, and the
other thing that I forgot to tell you is that whenever you show a
big diagram like this on a board or something else, it will
provide that information to everyone, and usually do it in a
public place in our, for example, project room, so that
everyone who is passing by can see that information, and
because of the fact that it’s sending information, it’s radiating
information, one generic term for that is Information Radiator.
 05:19 – Yeah, the title was up there, but I missed that. Okay,
so back to the diagram.
 05:24 – So, one way to show changes in the Product Backlog
is to use that second line and then you can connect them with
bars to show the amount of remaining work better than before,
so those bars are the amount of remaining work in this case,
and you will keep changing.
 05:43 – If you get something done, you will apply it to the first
line, which is the top of the bars and if you add or remove
something to your Product Backlog, it will be applied to the
second line, which is the bottom of the bars, and then you can
have the same trend lines and forecast for the completion
date, but it’s not important.
 06:05 – I just wanted to tell you one or a few alternatives on
how to present the information.
 06:11 – So, this is a Burn-Down chart, but if you want, you can
use a Burn-Up chart, which is a more old-fashioned way of
showing information and it makes more sense because
progress is a good thing, and when we are visualizing
information, we want to assign good things to the other good
things. So, going up is also considered a good thing.
 06:38 – It’s a visual indicator of good things.
 06:44 – So, Burn-Up chart is better in the sense that the good
thing, which is the progress, is created by another good thing,
which is going up. That’s one thing.
 06:57 – The other thing is that when you have changes in your
Product Backlog, instead of doing crazy things, you will just
add it to the top of the diagram, like we always used to do, and
if you want, you can have a line to track those changes, and
still if you want, you can turn it into a bar chart and when you
turn it into a bar chart, the normal name for this type of
diagram is a Cumulative Flow Diagram, and you can remove
the gaps, and you will get this, which is the same as before
obviously, but this is the more common way of showing
Cumulative Flow Diagrams in manufacture.
 07:42 – Just to let you know, that’s it, that was all.
 07:46 – So, my whole purpose for this lesson was to tell you
about different types of Information Radiators, the Burn-Down
charts, and the alternative, that is the Burn-Up chart.
 07:56 – The only things that you need to know for your exam
is that the Burn-Down chart shows the amount of remaining
work across time, and the Burn-Up chart, the opposite, the
amount of “Done” work across time, and the trend line can
show you a simple forecast of the completion date and what
else you have important, and none of these are mandatory for
you in your project.
 08:19 – You can use any visualization or any type of
calculation that you want.
Lesson 27: Agile Practices
 00:05 – There are a few practices and techniques that you
need to know as a Product Owner, and I have decided to tell
you about all of them by reviewing the Daily Routine in XP,
eXtreme Programming.
 00:22 – Extreme Programming is one of the oldest Agile
methods and it’s how most people, many people, got to know
about Agile.
 00:33 – It was great, and even Scrum was practically created,
according to some people, in order to be a layer above XP and
get it to work in a more productive way, and in the beginning,
there were … there were a lot of things about … from XP in
Scrum, but later on, gradually, they dropped more and more of
those things and Scrum became more abstract, if you will.
 01:07 – So, it’s a good idea to learn them through XP because
in here all practices are connected together and they create a
really productive whole, that’s important. It’s all about systems.
 01:21 – So, we have this Daily Routine in XP, and what we do
is that first, we, the developers get together in the morning,
and by first I mean first thing in the morning, and pair up.
 01:35 – People in XP work in pairs of developers and it’s
called Pair-Programming.
 01:42 – What happens here is that two people are working
together, they are sitting side by side.
 01:49 – One person is writing code and the other person is
observing and giving comments.
 01:56 – Every once in a while, they switch places. This second
part is important.
 02:02 – For example, every half an hour, and you see how
great it is because you learn a lot from each other, a lot of tips
and tricks and techniques in programming, and also you have
a second pair of eyes when you’re developing that can help
you prevent many problems and have audit reworks and many
other things.
 02:25 – Many managers are afraid of this because they feel
like they’re losing one of their resources without gaining much,
but in practice because of the higher quality that we have, we
will really gain more and it becomes justifiable.
 02:44 – So, because we must use Pair-Programming in XP,
it’s not a must in Scrum, it’s just an optional practice.
 02:52 – Because we must do that in XP, the first thing you do
in the morning is that you pair up, and preferably with
someone new. You don’t pair up with the same person each
and every day.
 03:04 – Then, the two of you will go in front of a board that
contains items, something like a Product Backlog or a Sprint
Backlog, and you will pick one of the items, and you will also
tell other people about it. “Is it okay if we pick this item? No
objections? Okay.” That’s your task for the day.
 03:26 – And one of the practices that we have here is what XP
calls Collective Code Ownership, which means that no person
or group own a part of the code base.
 03:38 – They cannot say that, “No one else is allowed to touch
this part, this is mine.
 03:42 – If you need something, you have to tell me and I will
apply it.” We don’t have that.
 03:47 – This practice is also reflected somehow in Scrum
when we say that they share accountability or something. I
cannot say that this is not mandatory in Scrum, it’s almost
there, but it is not advertised a lot. So, now they have the task
and they go in front of a board probably, but it can use a piece
of paper, and design it.
 04:14 – They think about the architecture of the feature they’re
going to develop, and in here, we have another principle,
another practice called Simple Design.
 04:24 – In case you’re into programming, those are one of the
main things that you have to take care of.
 04:31 – For example, you shouldn’t have duplicate code and
other things, but if you’re not into programming, don’t worry
about those things.
 04:38 – Just know that we need to have a simple design.
 04:42 – And then after they are done with their design, they go
behind their computer, one computer, and start programming
with Pair-Programming, but no, that’s too early. There’s
something else that they have to do.
 04:58 – Before programming, they create the tests, the tests
that describe when this feature is working, and in the
beginning when you’re creating those tests, they fail obviously
 because you still don’t have the feature, and this is something
we call Test-Driven Development.
 05:17 – You create a test first, you write the scripts for the test
and put them in your automated testing system, and then you
start writing the code, and it helps a lot because you always
have a full set of tests that you can run because you know that
in Agile, we are always integrating and releasing and so on,
and any change that you make to the system somewhere can
break something else, and that’s a nightmare for all of us in
every type of project.
 05:51 – So, what are you going to do? Are you going to test
everything every time?
 05:55 – It’s a great thing if you have automated tests that
cover everything, but if you want to create the feature and then
start creating the tests, chances are really high that your tests
won’t cover everything, but in here, when we use Test-Driven
Development, we usually have a complete set of tests, which
is really great for us. That’s one thing, and the other thing is
that when we approach the work like this, we are more
focused on the problem that we want to solve, and therefore,
we will be focused on that instead of spending our time on
fancy features.
 06:36 – The rule that we have is that we only create
something that makes it possible for the whole system to pass
the test. Alright.
 06:44 – So, in this step, we create the test scripts and put
them in the automated testing system, and then we start
writing the code.
 06:55 – Now, one of the rules in Test-Driven Development is
that you don’t create all possible tests before writing the code.
 07:03 – You only create as many tests as you need to create a
failing system and then you create enough code to make it
pass and then do the tests again.
 07:14 – Therefore, we have a loop here, but that’s not
important.
 07:18 – You understand what Test-Driven Development is,
and it’s not mandatory in Scrum obviously.
 07:23 – Then, after a while, you’re done. Your new thing, your
new feature is working and it passes all the tests, so that’s
great, but there’s one more thing that we have to do.
 07:39 – We sit down, go through the whole code, and improve
it.
 07:46 – We only improve the code itself, the architecture of the
code.
 07:50 – For example, make sure that no piece of code is
repeated anywhere, well, in different degrees, of course.
 07:58 – And that is something that I mentioned before. Do you
remember the name?
 08:03 – I just mentioned it quickly. It’s called Refactoring.
 08:07 – The Refactoring is improving the code without
changing its external behavior.
 08:12 – So, you see, it’s a really, really great system. You go
on, you create the tests first, then you create a feature, and
then when you’re done with the feature, you’re done, the
feature is working, everything is fine, but you still take your
time and refactor the code right there and then.
 08:31 – That’s how it works in XP. That’s how important
quality is for us, and it’s not time that we waste, you know.
Because of this, we are reducing our Technical Debts.
 08:42 – Technical Debt is the not so good things that we in our
code.
 08:49 – It doesn’t block the current things that we need, but
we know that if we go on like this, it will create problems in the
future.
 08:58 – For example, the code is too complex. Therefore,
even though it’s working now, in a few months from now, when
we want to add something else, it may break the whole
system, and then because of this complexity, we cannot
understand how to fix it.
 09:12 – Instead of spending a few hours, we may have to
spend a few days or weeks fixing that problem.
 09:19 – This is Technical Debt, and how do we solve that?
 09:23 – By doing Refactoring immediately after we create a
code. That is great. That is really, really great.
 09:31 – So, when you’re done with Refactoring, you will
integrate it into the system, and obviously you will run all the
tests and one of the rules that we have here is that anyone
who breaks the whole integrated system, those two … we
always have two people …
 09:48 – those two are responsible for fixing that. They will
never say that, “The part that is broken was written by those
two other guys, so they have to fix it.” No. You integrated it,
you created the problem, you just solve it.
 10:02 – We have Collective Code Ownership. We have shared
accountability here.
 10:08 – And the other thing is about the frequency of
integration. We are continuously integrating.
 10:14 – It’s not about integrating at the end of the iteration or
even more than that, it’s not even about integrating once a
week.
 10:24 – We are probably integrating multiple times per day,
and that is important because you can never be sure that the
work …
 10:34 – that the code works properly unless you integrate it.
 10:39 – The biggest problem that we have is when you add
something and it breaks something else in the system.
 10:44 – So, that’s it, and then the other rule that we have is
that when it is time, you will stop working because we have
Constant Pace. It used to be called a 40-hour work week in
XP, but as it turns out, in some countries, some people work
less than 40 hours a week.
 11:07 – So, Constant Pace is more generic. It’s a good thing.
 11:11 – What it means is that you don’t say that, “Okay, we’re
almost there.
 11:15 – If we spend just one more hour, we will be finished
with this.” No. Let’s be relaxed. If you’re not done, if your code
doesn’t work properly; for example, you’ve integrated the
code, you’ve run into some problems and you couldn’t fix it
yet, but it is time, you just roll back everything, you go home
and then you will continue the next day.
 11:41 – Now, we do that because it’s more productive. Alright.
 11:45 – What do you think about Releases? When should we
release in Scrum?
 11:50 – We are done with XP by the way. So, everything that
we heard here, these are practices that are mentioned in your
exam by the way.
 11:57 – Some of them are optional in Scrum, some of them
are not optional.
  12:00 – For example, Continuous Integration, that’s something
that we have in Scrum.
 12:06 – Now, something that we didn’t talk about so far is
Releases.
 12:11 – What do you think we should have as Releases in
Scrum? That’s our topic for the next lesson.

Lesson 28: Releases

 0:05 – One of the things that we talked about in the second
section of the course, which was about the ideas behind
Adaptive systems was that we have to have increments at the
end of each iteration because we need to show them to the
customer, receive feedback, and see what’s the best next
thing to do.
 00:24 – That’s Adaption. It doesn’t work without that.
 00:28 – Now, it’s important for us to have releasable
increments.
 00:34 – Something that is potentially releasable, potentially
usable for the end-users, or something like that, and all that it
means is that it must be absolutely complete.
 00:48 – You don’t have, for example, untested features there
because there’s a chance that it may not work properly, and
therefore it won’t create a complete experience for your
customer and therefore you won’t be able to receive proper
feedback.
 01:04 – That’s obviously one of the reasons. The other reason
is that if you just keep things hanging there for some future,
the whole system won’t be reliable.
 01:17 – Instead of working on many different things in the
same time, just limit yourself to a few items, get them 100%
done, then go on with the next things.
 01:32 – That’s more productive, and that will create
increments that are releasable.
 01:38 – So, remember that every increment must be
releasable, but it doesn’t mean that we release all of them.
 01:46 – Releasing is not that easy. You’re changing something
in operations.
 01:53 – You may need to train people. You have some risks.
You may be you may have to be aligned with other parts of
the business.
 02:03 – So, it may not be possible for you to release all the
time.
 02:07 – You may want to release every few Sprints or in some
cases, maybe you want to release only at the end of the
project, but still all increments must be potentially releasable,
okay?
 02:18 – Now, there are two main advantages when we really
release the product.
 02:24 – Can you say what?
 02:28 – One advantage is that we are using the software and
we can generate money as a customer, and that’s good.
 02:37 – You don’t have to wait one year, for example, before
we can generate any money.
 02:42 – Maybe we can start using it and generate some
money and then with more features that we will add in the
future, we will generate more money.
 02:50 – That’s a great option, but something else that is even
more important is that we can generate more serious
feedback.
 03:01 – If you don’t have releases, you’re limited to receiving
feedback from your customer and a few sample end-users, but
when you really put it into production and real end-users are
using it, then you can get feedback from those real people who
are the most important ones.
 03:21 – Your customer may even say something that doesn’t
make sense.
 03:26 – If you don’t have the user feedback, then that’s all you
have, but when you have the user feedback and conflicting
customer feedback, then you can justify the approach to giving
preference to the user feedback.
 03:44 – The customer should be able to understand it. You will
bring the numbers, you will show them how it works, and when
I say feedback, it doesn’t mean only asking people what they
think about something.
 03:55 – You can watch people and see what’s happening.
 03:59 – You can have every type of analytical information in
your system and use that as the feedback.
 04:07 – You can even do split testing when you have two or
more alternatives, see which one is more successful, and
assign people to these alternatives randomly.
 04:20 – So, that’s a randomized experience.
 04:22 – You will see which one works best and then you will
continue in that pattern.
 04:27 – That’s great, and you can’t do it without releases. So,
release, if you can.
 04:33 – So, as I told you before, whether or not you’re
releasing, everything that you put into your increment must be
100% complete, and how do you know if that’s 100% complete
or done?
 04:49 – That is based on the Definition of Done. So, don’t
worry about that.
 04:53 – And now one important question. What’s the most …
 04:59 – what’s the maximum number of releases that we can
have in a Scrum project?
 05:06 – Some people say once per Sprint.
 05:11 – That is not exactly right. We can have even more than
that.
 05:15 – You can have releases in the middle of the Sprint.
 05:18 – Can you explain why? Can you explain why some
people think that the maximum is once per Sprint, and why this
is not true?
 05:30 – The reason is that we shouldn’t confuse the Sprint
Review and Sprint Retrospective, especially the Sprint
Review, with accepting the product or repackaging the
product.
 05:46 – The Sprint Review is not about accepting the product,
the formal acceptance of the customer or anything else.
 05:53 – There’s only one real purpose for the Sprint Review.
What is that?
 05:58 – Receive feedback. Alright? So, it’s not about
acceptance, and therefore that doesn’t have any direct
relationship with releases, and on the other hand, you are not
supposed to be limited to the end of the Sprints to have those
complete packages.
 06:19 – It can happen every day. If you do it properly, if you
have continuous integration, if you have a proper automated
 system, then you are ready to have releases almost all the
time.
 06:33 – And that’s what happens in DevOps, for example, they
have really, really frequent releases.
 06:39 – They make small changes, but those changes are
controlled because we have tests, automated tests, and we
have really good channels of receiving feedback from the
users.
 06:52 – We will just go on, release them maybe every other
day, capture the feedback, go on, and maybe every two weeks
or one month, we can get together with the customer or
business people, if you will, review and talk about more high-
level approaches to the project.
 07:13 – So, what I mean is that your customer feedback, your
Sprint Reviews, can be focused on the more high-level
aspects of the project and then the details of your project can
be all based on the feedback that you receive from your users
based on the frequent releases that you have.
 07:32 – Okay, so that was it about releases, and in your
opinion, when should we prepare our whole infrastructure? For
example, I mentioned automated testing.
 07:45 – You need to do … to have something to make it
possible for you.
 07:49 – When do you prepare for your project in Scrum?
 2020 Update
 So, as you see here, when we say that there can be multiple
releases in a single Sprint, it implies that we can have multiple
Increments in a Sprint. It was implied in the previous versions
of the guide, but it wasn’t explicit. Now, it is clear that an
Increment is not a package you create at the end of the
Increment, but each time you finish an item during the Sprint, a
new Increment is formed. All of these increments are usable
(potentially releasable), but you don’t have to release all of
them.
 The term “potentially releasable” was confusing for some
people, and therefore, the new guide refers to it as being
usable, instead of potentially releasable. “Usable” is a
conservative term that is not as clear as “releasable”, but when
you think about it, it’s usable when it’s releasable.
Lesson 29: Sprint Zero!
 00:05 – So, when do you prepare for your project? Prepare
the infrastructure, for example.
 00:12 – Or the Product Backlog. You already know about the
Product Backlog. We talked about that.
 00:17 – You only spend a few days in the beginning of the
project before starting the Sprint, and as soon as you have
enough for the first Sprint, you will go on because you want to
adapt, but for the rest, some people consider something they
call Sprint Zero, where they spend equal amount of one Sprint
on preparing the infrastructure for their project instead of
developing.
 00:46 – This is unacceptable in [Link] and almost every
other credible resource about Scrum, and the reason is that
it’s not productive enough and it’s based on the fact that we
know upfront what we’re going to need in the project, and one
of the negative consequences is that the way you prepare your
project, if it’s done upfront, may lead you into a certain path in
the project which is not 100% adaptive.
 01:24 – It will force something into your project. It may block
adaptation. That’s why we don’t want it.
 01:30 – We don’t have the Sprint Zero, and our preparation for
tools and infrastructure will be done gradually during the
Sprint. Most of it will be done in the first few Sprints, but in
addition to that, we will also develop some real features, we
will receive feedback, we will have adaptation, and so on.
 01:52 – What we really want to do the old-fashioned way is
that you only prepare something when you need it for one of
the user stories.
 02:03 – We don’t have any technical things the old-fashioned
way.
 02:07 – In [Link], for your exam, you can have anything in
your Product Backlog, okay?
 02:12 – But the old-fashioned way is that we don’t have any
technical things in our Product Backlog.
 02:16 – For example, you don’t have anything about setting up
your database.
  02:20 – So, when do you do that? The first time you need a
database.
 02:25 – Whenever you have a user story or item that needs to
be connected with the database, you will set up your
database.
 02:34 – And what you see here is one of the reasons that in
the beginning of the project, our velocity is lower than the later
future Sprints.
 02:44 – The other thing that [Link] is very sensitive about
is something like the Hardening Sprint or Integration Sprint,
things like that, and this is not acceptable because we are not
supposed to wait for a certain time in the future to solve the
problems or to refactor or integrate.
 03:10 – We want things to be done before we go on and start
working on the future items.
 03:16 – It makes everything more reliable and more
productive, and we also have proper increments that we can
show to our customers.
 03:24 – Our increments must be potentially releasable.
 03:29 – However, there’s still, for example, SAFe, the Scaled
Agile Framework, which many people are against because it’s
not exactly aligned with Agile Principles, but really big
organizations like it because it creates the illusion of control,
but in say, for example, there are things like this and that’s
probably one of the reasons that [Link] is so sensitive
about them and have many questions about them in the exam.
They want to make sure that people know that at least based
on [Link]’s approach to Scrum, these things are wrong.
 04:13 – So, when do we do Hardening and Integration?
 04:16 – You do it all the time, during all the Sprints.
 04:20 – Alright. What is the measure of success?
 04:27 – That’s what we’re going to talk about in the next
lesson.

Lesson 30: Success

 00:05 – Okay. We work, like the way we talked about here.
 00:11 – We have Sprints, we create Increments, we have
Sprint Reviews, Sprint Retrospectives to improve the way we
work.
 00:17 – We plan again and go on, and it’s very natural for us
to want to know if we are successful, and different people
come up with different ideas about success, which is always a
very important measurement in our projects. We have many
problems with that.
 00:37 – There are many people out there who think that we
are successful in Scrum, for example, if we complete all items
that we have in the Sprint Backlog.
 00:49 – Some other people believe that we are successful
when we are increasing our velocity and things like that.
 00:58 – It is not the best way of understanding success
because, for example, the first one.
 01:05 – What is the problem with that, in your opinion?
 01:10 – The problem is that it all depends on how many items
we pick from the top of the Product Backlog for our Sprint
Backlog.
 01:19 – If we pick fewer items, then chances are higher that
we will deliver all of them, and therefore, if that’s going to be
your main measure of success, then automatically the
developers will be more conservative and they will pick fewer
items for the Sprint Backlog, and as we talked about before,
because of the Student Syndrome and the Parkinson Law,
work expands to fill in the available time, and they will end up
delivering fewer items. That’s why we don’t want it to happen.
 01:51 – You never, you should never blame people why they
didn’t deliver everything.
 01:56 – It was just a very rough idea in the beginning, and do
you remember the values in Scrum that we talked about?
 02:04 – One of them is commitment, and some people
consider commitment as related to this.
 02:11 – When you create your Sprint Backlog, you must be
committed to delivering all those items.
 02:17 – That is not the commitment that we talk about here.
 02:21 – Our commitment is to create a proper product that has
enough value and it’s related to what the end-users and the
customer want, and so on. That’s the commitment.
 02:33 – It’s not a commitment for delivering everything
because if you have that type of commitment, then
automatically you will pick fewer items and you will deliver
fewer items.
 02:45 – We don’t want that to happen.
 02:48 – And what’s the problem with the second one?
Velocity?
 02:53 – The problem with that is … well, let me ask you like
this.
 02:58 – What’s the easiest way to increase velocity?
 03:02 – The easiest way is to add more to your estimates
gradually.
 03:10 – You … the developers are responsible for estimating
the size and something that could be estimated as 10 Story
Points, for example, you just estimate to be 11 or 12, and after
a while, 13 or 14.
 03:25 – That’s the fastest and easiest way to increase your
velocity.
 03:30 – So, if your measure of success is velocity, then how
do you want to avoid that problem?
 03:37 – I’m not saying that people do it intentionally, but it may
happen automatically because people want to feel good about
themselves.
 03:47 – They want to be seen successful … as successful
people.
 03:51 – That’s one problem, and the other problem is that
even if you don’t do that, still velocity is all about speed.
 03:58 – Speed in which direction, that’s important. We don’t
have direction there, and direction is more, even more
important than speed for us.
 04:08 – So, what is the right measure of success?
 04:14 – All we want to do is to generate value.
 04:21 – When you increase value, you’re more successful.
 04:27 – That depends to the theoretical amount of value that
you could increase and so on.
 04:34 – I’m never saying that it’s easy to measure, but value
should be what you have in mind when you’re thinking about
success. But there are other things that we can use.
 04:45 – For example, the customer satisfaction or end-user
satisfaction.
 04:49 – That is directly connected to value and it’s much
easier to measure.
 04:56 – That’s why the customer satisfaction and end-user
satisfaction is very important for us.
  05:02 – Now, in your opinion, which one is more important, the
customer satisfaction or the end-user satisfaction?
 05:12 – The end-user satisfaction is more important.
 05:17 – That’s right. You’re receiving the money from the
customer, they own the product, but the fact is that if you keep
your customer satisfied, but you don’t satisfy the end-users,
that product won’t be able to generate enough value and
sooner or later, your customer won’t be satisfied anymore, and
the opposite, if your customer is not 100% satisfied, but the
end-users are really happy with the product, they will generate
more value and your customer will also become satisfied.
 05:53 – So, in short, one of the best and easiest way to
understand the success of our project is to think about the
end-user satisfaction. Alright.
 06:07 – So, we talked about the details related to product
ownership when we have the normal default setting, when we
have one team. Sometimes, we need to have more than one
team.
 06:20 – That’s called Scaled Scrum, and we’re going to talk
about it in the next lesson

Lesson 31: Scaled Scrum

 00:05 – Agile systems were initially created and used in small
and relatively simpler projects.
 00:14 – That’s a fact, almost, but still we have some
differences here.
 00:20 – For example, DSDM, which is another first-generation
Agile method.
 00:25 – It was initially created for bigger projects and, for
example, by default it supports multiple teams, but Scrum, for
example, the default in Scrum is that you have one team.
 00:40 – Now what happens if you want to have more than one
team?
 00:44 – Some people say that Agile by nature doesn’t apply to
larger projects.
 00:53 – Some people are against that, but most people who
are into Agile say that you can scale it up and use it when you
have multiple teams, but when it comes to Scrum, there are
 different ways of doing that, and we have different methods of
scaling Scrum.
 01:12 – Less and SAFe are well known. There’s also Nexus
from [Link] or Scrum@Scale or some other things, and
there’s also this idea of how to scale Scrum that doesn’t really
have a name, but comes with a few dos and don’ts. I usually
call it the no-name approach to scaling Scrum.
 01:39 – That’s the one that is based on having the Scrum of
Scrums, and some people even call it the Scrum of Scrums
approach to scaling.
 01:49 – For the PSM and PSPO exams, there are some
questions about scaling, but they are not based on any
specific method to scaling and, for example, even though
Nexus belongs to [Link], they don’t use Nexus for these
questions exactly.
 02:10 – And in return what they do is that they are more
focused on some generic aspects of scaling, that they believe
should apply to every type of scaling, correct?
 02:22 – And that’s what we’re going to talk about here, mainly.
 02:26 – So, first we have only one thing.
 02:29 – One Product Owner, one Scrum Master, and a
number of Developers.
 02:33 – Now, one way of adding more teams is to just copy
and paste and have more of those things, and because we
have multiple Scrum Masters and multiple Product Owners,
you may be thinking that we need to have some type of
coordination here, and therefore, you can think of a Chief
Scrum Master and a Chief Product Owner, and this is in fact a
model that is used in many of the approaches to scaling
Scrum, but it is not acceptable in [Link].
 03:11 – In [Link], they believe that there should always be
one Product Owner.
 03:16 – Now, can you think of … think about the advantages
and disadvantages of having one Product Owner?
 03:28 – The most important advantage is that the Product
Owner is the person who is responsible for managing the
Product Backlog and making sure that everyone has the
correct understanding about the features, right? Now, if you
have more than one person, there may be some
inconsistencies in your project.
 03:45 – It’s much easier if everything is done by one person,
and that’s the main driver for [Link] to say that we have
only one Product Owner, but on the other hand, what happens
is that when you have many teams, it becomes difficult for one
person to do all of that, and that is the reason that in other
systems, they have more Product Owners.
 04:11 – They have local Product Owners and a Chief Product
Owner that supervises all of them and so on, but for you, for
your exam, there is always, and it’s very important for the
PSPO exam, there’s always only one Product Owner for one
project.
 04:28 – Now, how many Product Backlogs do you think we
should have?
 04:35 – It’s always one because if you have more than one
Product Backlog, then it would be very difficult to order the
items, to prioritize the items, and see where we’re going with
the project.
 04:49 – That’s why in every system almost, yeah, in every
system, we have only one Product Backlog.
 04:55 – What about the Sprint Backlogs? Here, we have
multiple Sprint Backlogs, one Sprint Backlog for each team
because that’s the plan that we have for the team.
 05:06 – We don’t want to share everything among the teams,
then that would be like having one bigger team, it’s not
separate teams.
 05:14 – So, to let them know what they want to do, let them
have something to focus on and be productive, we create
separate plans for them, separate Sprint Backlogs.
 05:26 – Now, when they work together during the Sprint, they
will have their normal Daily Scrums, and what was the purpose
of Daily Scrums? To synchronize the developers with each
other.
 05:41 – Now, after each Daily Scrum, one representative from
each Scrum team goes to a virtual team and there they will
have Scrum of Scrums, and that’s something similar to the
Daily Scrum, but instead of trying to synchronize developers
with each other, here we will be synchronizing the teams with
each other, and they will probably go through the three normal
questions and they have one extra question that you see
there.
 06:16 – And just in case you don’t remember, for the Daily
Scrum, it’s not mandatory to go through those three questions.
 06:27 – It’s recommended, it’s the most common thing, it’s a
good idea, but you don’t have to, based on the latest updates
to [Link].
 06:36 – One … that’s one alternative, for example, for the
Scrum of Scrums.
 06:40 – The other alternative is to go through questions like
that, but anyway, that is the idea for Scrum of Scrums, but
there used to be questions about Scrum of Scrums in the
PSPO exam, for example, and PSM, but I’m not sure if they’re
going to keep them for the future because it doesn’t exist in
Nexus, so it’s not generic. It’s just one way of doing that, but
still you need to know.
 07:06 – Alright. So, they work, they create the features, and
what do you think about the outputs? What do you think about
the increments?
 07:18 – They have to combine all their outputs and create
Integrated Elements, Integrated Increments.
 07:29 – That’s absolutely necessary because if they keep their
outputs separate, then it is not integrated.
 07:35 – You can, it can never be reliable. You never know if
they can work together properly.
 07:41 – It must always be integrated for the whole project.
 07:45 – Now, something that is a little bit confusing for many
people, including me, is about synchronizing the Sprints. In
your opinion, should we synchronize the Sprints or not?
 08:03 – Alright. One idea is to say that when we have multiple
teams working on the same project, we should have
synchronized Sprints because we want to have Integrated
Increments at the end of each Sprint, right?
 08:20 – But that is not mandatory based on [Link]. You
can have Sprints with different sizes.
 08:28 – That’s how it is. And they believe so because that
gives more flexibility to the teams.
 08:37 – Maybe different teams are working on different parts
of the software and they have different needs.
 08:44 – For example, they need more feedback or they need
more retrospectives.
 08:48 – In that case, we allow them to do so, but still we can
try to make them less or more compatible.
 08:57 – For example, here you see that they are not
completely synchronized, but at least every once in a while, all
the Sprints are finished together. That’s the least we can do,
but still if it’s me, I would say let’s have synchronized Sprints.
That’s much easier.
 09:18 – Alright. So, I told you before that they combine their
outputs and they create Integrated Increments.
 09:26 – Now, what about the Definition of Done? Because this
is an increment, and like every other increment, it must be
potentially releasable all the time, and how do we know that?
That is all based on the Definition of Done.
 09:41 – Where does it come from? And who’s responsible for
creating the Definition of Done?
 09:50 – I don’t remember if we talked about it before. Just
forget about scaling, let’s go back to the default mode. Who’s
responsible for creating the Definition of Done? Do you know
that?
 10:00 – Inside the project, it is the responsibility of the
developers.
 10:06 – You may be thinking that the Product Owner should
also have a say, but it’s the developers.
 10:13 – So, back to the scaling here. The main question is
should we have only one Definition of Done or can we have
multiple Definitions of Done? What do you think?
 10:24 – Alright. We can have multiple Definitions of Done as
long as they are compatible with each other and they can
create the Integrated Increment, and that’s because part of the
Definition of Done is about our approach to quality.
 10:44 – Maybe some of the teams prefer to have more tests.
 10:49 – Why not? Why should we tell them that you shouldn’t
do it like that?
 10:54 – If what they are doing is compatible with what
everyone else is doing and doesn’t create problems for our
integration, then it’s fine. Let them have a different Definition of
Done.
 11:04 – That’s what [Link] says, not me. And by the way,
I know that what you see in the Scrum Guide seems like
 there’s only one Definition of Done, but that’s not what is
expected from you in the exam, okay?
 11:19 – In case you are matching what I’m saying with the
[Link]. The Scrum with the Scrum Guide.
 11:26 – The [Link] says this and this is expected from you
in your exam.
 11:31 – Now, to give you a better idea, let’s see it like this.
 11:35 – The original, the minimum Definition of Done may
come from your organization level.
 11:42 – Also in the default one team setting. So, it’s not only
by the developers.
 11:48 – The minimums can come from the organization
because sometimes the organizations want to have a
minimum level of consistency among different projects.
 11:59 – You may have some coding standards there. That’s a
good idea, in fact.
 12:04 – So, the organization tells you about the minimums that
you must have in your Definition of Done in the project.
 12:10 – You receive that and then depending on the type of
the pro– type of project that you have, you may need to add
more constraints to your Definition of Done.
 12:22 – And that’s what you will all do together and create a
Definition of Done, or at least a virtual Definition of Done that
applies to the whole project.
 12:33 – And it will be compatible with the one coming from the
organization level because you only added constraints, you
don’t remove the existing constraints.
 12:42 – Now most of the things that we have in the Definition
of Done are constraints.
 12:47 – For example, one rules says that you’re not allowed to
call something “done” unless you followed this coding
standard. The other one says you should also have this and
that type of test.
 13:04 – Doesn’t say that it’s fine if you don’t follow the coding
standards.
 13:08 – That is in place and then you add a few more
constraints.
 13:13 – Now, you have the Definition of Done for the project
level and then, if you want, each team can add a few more
 constraints for their own team, and again here all we do is that
we add more constraints there.
 13:28 – Therefore, what we have in the team level is still
compatible with the project level Definition of Done.
 13:35 – And therefore, we can combine all the outputs and
create an Integrated Increment.
 13:42 – That was a lot. Alright.
 13:46 – We’re almost there. Just one more thing. When you
are forming the teams, you have two generic approaches to
creating the team.
 13:54 – One of them is to have different teams for different
components of your system.
 13:59 – For example, one team for user interface, one team
for security, one for database, and so on, and the other is to
have feature teams that have all components inside the team.
 14:12 – Which one is the better option for us?
 14:15 – I think that’s easy. It’s the second one because we
need to have cross-functional teams here, remember the basic
characteristics of a team. That’s there.
 14:27 – And it’s important because with the component teams,
you cannot finish any …
 14:32 – many, at least, many of the items with one team.
 14:37 – You have to send and receive items and that creates
a lot of problems.
 14:42 – It’s not productive enough, but with the Feature
Teams, you can give the items to any of the teams and they
can do it. That’s fine.
 14:52 – They can have their own Sprint Backlogs and go on.
 14:56 – Alright. That’s everything we need to talk about
Scaling Scrum.
 15:00 – If you need to know, if you would like to know more
about it, then you should pick one of the scaling systems,
there are not really more than these generic things, and even
some of the things that we talked about here are not generic.
For example, about the Product Owner.
 15:17 – Here we say that you must have only one Product
Owner, but some methods say that you can have more.
 15:23 – So, the only way for you is to pick one of the scaling
methods.
 15:26 – It can be Nexus, it can be Scrum@Scale, it can be
Less. Go and learn about that.
 15:36 – We have just one more lesson and it’s going to be
about budgeting and contracts, just a little bit.

2020 Update

An interesting change in the new version of the Scrum Guide

is that it’s considered the responsibility of the whole Scrum
Team to define the Definition of Done, and not only the
Developers. This is so, because Definition of Done is not only
a technical concept, and it has business and process aspects
as well.

Lesson 32: Budgeting

 00:06 – It’s the last lesson. Alright. Let’s get into it.
 00:11 – This one is about Contracts and Budgeting.
 00:15 – When it comes to contracts, we have a lot of problems
in Agile projects.
 00:21 – We can think of three generic types of contracts. One
is Time and Material.
 00:28 – That’s where you get paid based on the amount of
time that you’ve spent on the project and you don’t buy
material here, it’s not a construction project.
 00:39 – It’s also similar to Fixed-Unit contract for us here, but
don’t worry about that.
 00:46 – The other type of contract is Fixed Price. Your
favorite, I know that, but with Fixed Price, we can still think of
two different types of Fixed-Price contract.
 00:57 – A Fixed-Price contract that has a dynamic scope and
a real Fixed-Price contract with fixed scope.
 01:05 – That’s what we mean, everyone means by a Fixed-
Price contract.
 01:10 – Now, for a Time and Material contract, we don’t need
an upfront plan because we will get paid based on how much
time we are spending.
 01:22 – For a Fixed-Price contract and dynamic scope, a high-
level plan would be enough, but when you have a Fixed-Price,
Fixed-Scope contract, you really need to have a complete
scope of the project and that’s done by planning.
 01:38 – So, what you need to have is a really detailed upfront
plan, relatively detailed upfront plan, but you need to know,
you need to think about every aspect of the project.
 01:50 – When you say that, “I want this feature in my
software,” you have to describe what you want from that
feature.
 01:59 – So, which one is the best type of contract for Scrum?
 02:04 – Obviously, the first one. When we have a Time and
Material contract.
 02:09 – The second one is a strange type of contract that is
used in DSDM.
 02:13 – There, we use the MoSCoW prioritization in the
beginning of the project and what we say in the contract is that
we guarantee that we will deliver all the Must-Haves, we will
do our best to deliver the Should-Haves, and we’ll see what
happens with the Could-Haves.
 02:29 – That’s the type of contract. It’s very strange and not
many people use that.
 02:34 – And the last one, which is Fixed-Price, Fixed-Scope,
that is not Agile and that’s the problem.
 02:40 – Still, there are many customers out there who come to
you and say that, “We want you to do this project in an Agile
way, and by the way, we need to have a Fixed-Price contract.”
They just don’t match. In a Fixed-Price contract, that fixed
price is based on fixed scope.
 03:02 – That’s based on trying to understand everything
upfront.
 03:06 – That is not Agile. In Agile, we want to go on, as we
discussed before, and find our way.
 03:13 – During our Agile journey, we will define and discover
the scope of the project.
 03:22 – We will see what’s best, what the end-users like most.
 03:27 – So, we don’t know it in the beginning, how can we
have a Fixed-Price contract, but still there are many of them
out there, and there are some approaches on how to cope with
a Fixed-Price contract.
 03:38 – It’s usually based on replacing the original items with
new items, but that brings a lot of contract negotiations.
 03:47 – Do you remember the Agile Manifesto? That is the
problem.
 03:52 – The other thing that we have here is about Budgeting.
 03:55 – When you create a contract, you need to have some
type of budgeting, and even for internal projects, you still need
to have an idea.
 04:03 – For example, the business side of your own company
comes to you as the IT department and tells you that, “This is
something that we need, a very rough description of the
project.
 04:15 – How long do you think it will take?” Which is equal to
how much does it cost?
 04:22 – So, you need to come up with a number. What would
you do? What’s your opinion?
 04:28 – It’s simple, I would say. You have to give them a very,
very rough idea.
 04:35 – For example, this is not your first project, so what you
would say is that, “In similar projects that we’ve done before, it
usually took between 6 months and a year, and it’s probably
what’s going to happen in your project.” That rough.
 04:53 – That’s what we can do because it’s Agile, it’s adaptive.
 04:56 – If you really want to be adaptive, that’s all you can do.
 05:01 – However, during the project, as you go on, not in the
beginning of the project, as you go on, your Product Backlog
becomes less or more stable.
 05:11 – You have an idea of the volume of work, size of work,
and then using your velocity and the statistical information that
we talked about, you can forecast how much it takes to, for
example, finish everything that we have in the Product Backlog
and the things that they may add during the project because
as a Product Owner, you also have an idea on how many new
things will be added to the Product Backlog.
 05:42 – So, you will calculate that and you will update your
budget.
 05:46 – You will say that, “For everything that will come here,
for example, we need to have, we need to spend these many
months,” for example, 9 months, which is equal to money.
 06:00 – We can just replace it with money, that’s okay.
 06:03 – And then they may tell you that, “Okay, we don’t have
enough budget for that.” and you would say, “That’s fine,
because it’s Agile.” “How much budget do you have? How
much time do we have?” They may say, “We’ve got about 5
months,” and then you can go together throughout the Product
Backlog and see how much of the work you can deliver in 5
months.
 06:26 – Is it enough to create a reasonable product or do you
need to know it beforehand and try to get more budget and
add, for example, two more months to it if you want to have a
proper product, or if it’s absolutely okay.
 06:41 – That’s the type of budgeting that we have, which is
first of all done by you, the Product Owner, and secondly it is
always updated throughout the project, based on what
happens in the project, based on what you learn from the
project, but it’s never exact and it doesn’t have to be exact.
 07:01 – Okay. That was it and we are done with this course.
 07:07 – I really hope that you’ve enjoyed the course and
learned something that you can use, and also succeed in your
exam. Good luck!

2020 Update

OK, I’ve explained the changes on the bottom of the lessons

where applicable. Now that we’ve reached the end of the
course, it’s a good time to review all those changes:

 There’s no “development team” anymore, but only Developers.

 The recommended team size is now “10 people or less” for the
whole Scrum Team.
 It’s now called “self-managing” instead of “self-organizing”
(same concept, different name).
 There’s a Product Goal now, which is part of the Product
Backlog.
 The Sprint Goal is now considered as part of the Sprint
Backlog.
 The concept of commitments is introduced for the artifacts:
o Product Goal is the commitment for the Product Backlog.
o Sprint Goal is the commitment for the Sprint Backlog.
o Definition of Done is the commitment for the Increment.
 The Definition of Done is created by the whole Scrum Team
now, and not only by the Developers.
 Now, any time you finish an item (based on the Definition of
Done), a new Increment is formed. It’s not about having just
one Increment at the end of the Sprint.
 The guide doesn’t suggest 10% as the ceiling for the amount
of time Developers spend on Product Backlog refinement.
 Sprint Planning has three topics now:
o Why? -> Sprint Goal
o What? -> Items from the Product Backlog
o How? -> Tasks created by decomposing the items
 “Estimating” is now called “sizing”. So, it’s the responsibility of
the Developers to size the Product Backlog items.
 “Value” is no longer one of the mandatory attributes of the
Product Backlog items. The mandatory attributes are
description, size, and order.
 Instead of calling the Increments “potentially releasable”, the
new guide calls them “usable” (more or less the same
concept).