SCRUM F&A

Velocity: an optional, but often used, indication of the amount of Product

Backlog turned into an Increment of product during a Sprint by a Scrum Team,
tracked by the Developers for use within the Scrum Team.
Velocity is the average amount of work (typically measured in 'story points')
completed per Sprint. The velocity of previous Sprints helps the Scrum Team
anticipate the capacity for future Sprints.

Our highest priority is to satisfy the customer through early and

continuous delivery of valuable software.

2 Welcome changing requirements, even late in development. Agile

processes harness change for the customer’s competitive advantage.

3 Deliver working product frequently, from a couple of weeks to a couple

of months, with a preference to the shorter timescale.

4 Business people and developers must work together daily throughout

the project.

5 Build projects around motivated individuals. Give them the environment

and support they need, and trust them to get the job done.

6 The most efficient and effective method of conveying information to and

within a Scrum Team is face-to-face conversation.

7 Working product is the primary measure of progress.

8 Agile processes promote sustainable development. The sponsors,

developers, and users should be able to maintain a constant pace
indefinitely.

9 Continuous attention to technical excellence and good design

enhances agility.

10 Simplicity–the art of maximizing the amount of work not done–is

essential.

11 The best architectures, requirements, and designs emerge from self-

organizing teams.

12 At regular intervals, the team reflects on how to become more

effective, then tunes and adjusts its behavior accordingly.

A Scrum Team member should be cross-functional because the Scrum

Team as a whole should possess all the skills and competencies required
to complete a product increment. This concept is central to the Scrum
framework. Here's a bit more detail:
 1. Collective Responsibility: In Scrum, there's a collective
responsibility within the Scrum Team to deliver a potentially
releasable product increment by the end of each Sprint. This means
that the entire team is accountable for the work, not just individual
roles.
2. Self-Organization: Scrum encourages self-organization, where the
team determines how to accomplish the work effectively. Cross-
functional teams are better equipped to self-organize because they
have a range of skills to draw upon.
3. Reduced Dependencies: Cross-functional teams are less reliant
on external resources or specialists, which can create dependencies
and slow down development. When the team has a broad skill set,
they can work more independently.
4. Adaptability: The team's ability to adapt to changing priorities and
requirements is enhanced when team members can perform various
tasks. They can adjust their focus and take on different
responsibilities as needed.
5. Collaboration: Collaboration is improved when team members
have an understanding of each other's roles and can step in to
assist or provide insights. This fosters a sense of unity and shared
ownership of the work.
6. Efficiency: With a cross-functional team, there's no need to wait for
specific specialists to become available. This can lead to faster and
more efficient development cycles.
7. Potentially Releasable Increments: The goal of each Sprint is to
produce a potentially releasable product increment. To achieve this
goal, the team should have the skills to take a product backlog item
from concept to a shippable state within the Sprint.

While having cross-functional team members is important, it's also

recognized that there may be situations where specialists or experts are
needed for specific tasks or challenges. In such cases, the team can
collaborate with specialists, but the core team should still be cross-
functional to maintain flexibility and autonomy.

Explanation
1. The Developers may end up with less time in the Daily
Scrum to re-plan their work: If management attends the Daily
Scrum and actively participates, it can extend the duration of the
meeting, leaving less time for the Developers to re-plan their work
for the day.
2. The Developers may be less open and transparent during
the Daily Scrum: Knowing that management is present,
Developers might be less candid about challenges, impediments, or
issues they are facing. They may feel pressure to present a positive
image.
3. The Scrum Master may need to enforce the rule that only
Developers participate in the Daily Scrum: To maintain the
 integrity of the Daily Scrum, the Scrum Master may need to remind
everyone, including management, that only the Developers should
actively participate in the meeting. Observers can listen but should
refrain from interfering.
4. Additional facilitation may be required to keep to the time
box: With management's presence, discussions and questions may
arise that require additional facilitation to ensure that the Daily
Scrum remains within its time box. The Scrum Master may need to
guide the meeting more assertively.

These outcomes highlight the importance of respecting the purpose and

format of the Daily Scrum while accommodating management's need for
progress updates. It's essential to strike a balance to ensure that the Daily
Scrum remains effective in its primary goal of enabling the Developers to
plan their work for the day and address any impediments.

The Daily Scrum is a 15-minute time-boxed event for the Developers.

Which means 15 mins is the maximum duration, not the minimum. A Daily
Scrum can last less than 15 mins.

The Daily Scrum is held at the same time and place each day to reduce
complexity.

Daily Scrums improve communications, eliminate other meetings, identify

impediments to development for removal, highlight and promote quick
decision-making, and improve the Developers' level of knowledge. This is
a key inspect and adapt meeting.

Having multiple Product Owners for a single product can lead to confusion
among stakeholders. It is important to have a clear point of contact and a
single person responsible for managing the product's vision and backlog
to ensure effective communication and alignment.

- Having a single Product Owner ensures that there is clear accountability

for the ultimate value of the product. The Product Owner takes ownership
of maximizing the value delivered by the Scrum Team, making decisions
on behalf of stakeholders, and ensuring that the product meets their
needs and expectations.

- Having a single Product Owner ensures that there is clarity on who

determines the order of the Product Backlog. The Product Owner has the
authority to prioritize the backlog items based on stakeholder
requirements, market conditions, and business goals. This helps the
Scrum Team focus on delivering the highest value items first.

- "It would confuse the stakeholders if they had to work with more than
one person" is not one of the BEST 3 answers because everybody can
work with more than one person. It's just more convenient to discuss with
only one person.
Opportunities to inspect and adapt the Sprint Backlog are lost:
The Daily Scrum is a key event for Developers of the Scrum Team to
inspect their progress towards the Sprint Goal and to adapt the Sprint
Backlog as necessary. This meeting provides a regular opportunity to
assess what has been completed and to plan the next steps. By reducing
the frequency of this meeting, the team would lose valuable opportunities
to make timely adjustments to their work and the Sprint Backlog,
potentially leading to inefficiencies and delays in meeting the Sprint Goal.

Impediments are raised and resolved more slowly: One of the

purposes of the Daily Scrum is to identify and discuss any impediments
that may be hindering the team's progress. These impediments can range
from technical challenges to external blockers. If the Daily Scrum is held
less frequently, it means impediments may not be communicated and
addressed as quickly. This delay can cause slowdowns in the team's work
and affect their ability to deliver on time.

The Sprint plan becomes inaccurate: The Daily Scrum allows the
Developers of the Scrum Team to update each other on their progress and
re-plan the work as necessary. This constant re-planning helps keep the
Sprint plan accurate and aligned with the current state of the project.
Reducing the frequency of the Daily Scrum could lead to situations where
the team is working based on outdated information, making the Sprint
plan less reflective of the actual work being done and the challenges
being faced. This can result in misalignment between the team's activities
and the Sprint Goals.
In the context of measuring and tracking the creation and delivery of
value to the marketplace, the Product Owner in a Scrum framework
should consider the following Key Value Areas (KVAs):

1. Time-to-Market: This measures how quickly the team can deliver

features, products, or services to the market. A shorter time-to-
market can be a critical factor in achieving competitive advantage,
especially in fast-moving industries. It involves evaluating how
effectively and efficiently the team can move from ideation to a
deliverable product.
2. Current Value: This assesses the present value that the product or
service delivers to the business and its customers. It encompasses
aspects like user satisfaction, market share, revenue generation,
and overall quality of the product. Tracking current value helps the
Product Owner understand the impact of the product in real-time
and make informed decisions to maximize value.
3. Ability to Innovate: This KVA focuses on the team's capacity to
innovate and adapt to changing market needs or technologies. It
includes evaluating how quickly and effectively the team can
incorporate new ideas, respond to emerging trends, and improve
 the product. A high ability to innovate ensures that the product
remains relevant and continues to meet evolving customer needs.

These three KVAs - Time-to-Market, Current Value, and Ability to Innovate

- are crucial for the Product Owner to consider as they provide a
comprehensive view of the product's value delivery and market
competitiveness. By focusing on these areas, the Product Owner can
guide the product development in a way that maximizes value and aligns
with strategic business goals.

Time-to-Market is a Key Value Area (KVA) of the Evidence Based

Management (EBM) approach that expresses the organization’s ability to
quickly deliver new capabilities, services, or products. Customer
satisfaction is a Key Value Measure (KVM) under the Current Value KVA
that helps gauge customer engagement and happiness with the product.

But only the Developers may PARTICIPATE in the Daily Scrum.

"Attend" the Daily Scrum means you are present at the event as a silent observer when
participation means you step in and talk.

The following 12 Principles are based on the Agile Manifesto:

1 Our highest priority is to satisfy the customer through early and

continuous delivery of valuable software.

2 Welcome changing requirements, even late in development. Agile

processes harness change for the customer’s competitive advantage.

3 Deliver working product frequently, from a couple of weeks to a couple

of months, with a preference to the shorter timescale.

4 Business people and developers must work together daily throughout

the project.

5 Build projects around motivated individuals. Give them the environment

and support they need, and trust them to get the job done.

6 The most efficient and effective method of conveying information to and

within a Scrum Team is face-to-face conversation.

7 Working product is the primary measure of progress.

8 Agile processes promote sustainable development. The sponsors,

developers, and users should be able to maintain a constant pace
indefinitely.
9 Continuous attention to technical excellence and good design
enhances agility.

10 Simplicity–the art of maximizing the amount of work not done–is

essential.

11 The best architectures, requirements, and designs emerge from self-

organizing teams.

12 At regular intervals, the team reflects on how to become more

effective, then tunes and adjusts its behavior accordingly.

Explanation
1. The Developers may end up with less time in the Daily
Scrum to re-plan their work: If management attends the Daily
Scrum and actively participates, it can extend the duration of the
meeting, leaving less time for the Developers to re-plan their work
for the day.
2. The Developers may be less open and transparent during
the Daily Scrum: Knowing that management is present,
Developers might be less candid about challenges, impediments, or
issues they are facing. They may feel pressure to present a positive
image.
3. The Scrum Master may need to enforce the rule that only
Developers participate in the Daily Scrum: To maintain the
integrity of the Daily Scrum, the Scrum Master may need to remind
everyone, including management, that only the Developers should
actively participate in the meeting. Observers can listen but should
refrain from interfering.
4. Additional facilitation may be required to keep to the time
box: With management's presence, discussions and questions may
arise that require additional facilitation to ensure that the Daily
Scrum remains within its time box. The Scrum Master may need to
guide the meeting more assertively.

These outcomes highlight the importance of respecting the purpose and

format of the Daily Scrum while accommodating management's need for
progress updates. It's essential to strike a balance to ensure that the Daily
Scrum remains effective in its primary goal of enabling the Developers to
plan their work for the day and address any impediments.

Explanation
Key Value Measures are current value (CV), Time-to-Market (T2M), Ability
to Innovate (A2I) and Unrealized Value (UV). Operational cost reduction
and customer satisfaction are part of current value, but rest options are
not part of any key value measures.

Explanation
Impacts and inputs to the product roadmap can indeed include the
following valid elements:

1. Product Vision: The product vision provides a long-term, strategic

direction for the product. It outlines what the product aims to
achieve and serves as a guiding star for all roadmap decisions. The
roadmap is essentially a plan on how to realize this vision over time.
2. Internal and External Dependencies: These are critical factors
to consider when developing a product roadmap. Internal
dependencies might include resource availability, team capacity,
and technology constraints within the organization. External
dependencies can encompass market trends, regulatory
requirements, partnerships, and competitor activities. Both types of
dependencies can significantly influence the prioritization and
scheduling of roadmap items.
3. Value from a Customer Perspective: Understanding what brings
value to customers is a key driver in roadmap development. This
includes customer needs, preferences, feedback, and the evolving
market demands. The roadmap should reflect features and
enhancements that deliver the most value to customers, as this
alignment is crucial for the product's success.

In summary, a product roadmap is influenced by the overarching product

vision, internal and external dependencies that could impact delivery, and
the perceived value from the customer's perspective. These elements
help in shaping a roadmap that is not only strategic but also pragmatic
and customer-focused.

As a Product Owner, find a Key Value Indicator (KVI) for your product, which can
be measured early and often. Ensure that you deliver work that really has an
impact on your KVI(s), so that you are consciously steering on value. There is no
way you can 'determine' the value of a Product Backlog Item upfront. You could
make an estimate, you can take a guess, but you can't 'determine' the value.
Keep in mind that something is valuable, when you've released a Done Product
Increment to customers/users, and they've told you that the work you've
delivered is valuable.