Attend and actively participate in the Sprint Planning Meeting

PO comes to the Sprint Planning meeting with a Product Backlog that is well prepared

Teach that the Daily Scrum Meeting is the development team’s meeting

PO should be fully available to answer questions and clarify details that the development team requires in order to deliver their commitment

PO should not disrupt or interfere with the development team

the Sprint Commitment does not change, and that the Product Owner should not attempt to introduce new or changed items during the Sprint

in the event of a significant change in circumstances, the Product Owner may choose to terminate the Sprint and ask the Development Team to begin a new one

if the Product Owner identifies new requirements during the Sprint, they should be placed on the Product Backlog to be worked on in a future Sprint

Product Owner and development team should together decide the Sprint length

once the Sprint begins, its duration is never extended

Sprint commitment does not equal a guarantee

Roles: Scrum Master, PO, Team

Backlog

Sprint

Mandatory, cannot be compromised

Definition of Done

Iterative-incremental software development principles

Empirical process control

Scrum Culture

Commitment

Focus

Openness

Respect

Courage

What the project will create

For whom

why

Prioritized

Provides team context/detail team requires to deliver features/functionality

Provides whatever input/assistance the team requests

Engaged with the team throughout the Sorint

Identifies ways to improve business value

looks for insights about opportunities, constraints, risks...

Maintains clear release criteria

Except in event of major change in circumstances

such as Product Manager

Remove Waste

Product business value early and often

To the team

PO

Others in the organization

Helps the team remove obstacles and impediments

Protects the team from disruption

Coaches team on their practices

Team

PO

Responsible for working diligently to produce high-quality, potentially shippable functionality each Sprint

Works without sacrificing a sustainable pace of work

Works without sacrificing long-term quality of work delivered

Shared goal: product vision describes the common goal; it aligns the Scrum team members and stakeholders pulling everyone in the same direction.

vision should state the customers and users of the software, the needs addressed, and the most important product attributes. It may also compare the product to existing ones and state the revenue model.

Shared

Broad and engaging

Concise: captured on 1 or 2 flipcharts

Techniques

The upfront work in Scrum to create a product vision should be minimized; just enough work to create a vision that gels the team and creates forward momentum

Potential dangers

different products and domains require a different amount of prep work

Avoid fallacy of trying to predict the future

As the product matures and incremental updates are released, the visioning effort usually declines. New product versions still need to have goals to align the Scrum team and stakeholders. Visioning now forms part of creating and updating the product roadmap.

A product roadmap is a planning artifact that shows how the product is likely to evolve across releases and product versions, facilitating a dialogue between the Scrum team and the stakeholders.

Product Backlog

Tasks

Purpose of estimating

an accurate estimate may be useful even if its precision is lessthan the product owner would like

an inaccurate (but precise) estimate is of no use

estimates in Scrum are team estimates and should not include anyassumptions but who is going to implement a product backlog items or sign up for a task

the team should estimate the size of the effort and then velocity should be used to empirically determine the duration. Size and duration can independently

team members will provide low estimates when forced and won’t finish the work within that time

excessive time pressure leads to cutting quality (which comes back to hurt the project later), low morale, and loss of creativity

estimate is a prediction of the future and always includes some amount of uncertainty

a commitment is based on an estimate, which must be created first

implications of equating estimating with committing

The product backlog is a list of requirements and other deliverables necessary to turn the vision into a successful product. The product backlog must must be Detailed appropriately, Estimated, Emergent, and Prioritized (DEEP)

not a substitute for a requirements specification

evolves and changes constantly; many of its items are coarse-grained and sketchy to start with; they are then progressively decomposed and refined

emphasis shifts from documentation to conversation, from specifying requirements to having an ongoing dialogue

product backlog can have different forms and shapes

Steps to groom the product backlog such as discovering new requirements, and updating or removing existing ones; prioritizing the backlog; preparing high-priority items for the next sprint planning meeting; estimating items.

approaches to stocking the product backlog and determining the release scope such as deriving the contents from the product vision

just-enough requirements are identified and described just in time according to their priority throughout the entire project

grooming the product backlog is a collaborative effort shared by all Scrum team members

the product owner leads the efforts

members can spend up to 10% of their time on grooming

often involves customers and users and other stakeholders including marketing and sales

high-priority items to be worked on in the next sprint must be small enough to be fully transformed into a product increment. They should also be clear and testable.

Share at least one technique suitable to capture product backlog items, for instance, user stories

Share how non-functional requirements can be dealt with in the product backlog

it is important to prioritize the backlog because the team is expected to work in approximately priority order

because it is impossible to perfectly predict a schedule and the contents of a release, there is always the chance that a product will need to be shipped sooner than planned or with fewer features

a prioritized product backlog enables the team to maximize the delivery of value to the customer over a given period of time

prioritizing a product backlog involves both determining what product backlog items will be planned to be in the upcoming release and the general sequence in which they will be built

it is important to prioritize work even on a fixed-scope project for which all features are mandatory

since not all work can be done simultaneously, even a fixed-scope project will still benefit from prioritizing work at the start of each sprint

even though a team plans and commits to deliver all features on a fixed-scope project, that does not always happen: Project schedules are sometimes shortened, teams make mistakes, and so on.

it is important for the product owner to incorporate the opinions of many diverse stakeholders

opinions about priorities should be sought from users, customers and other business-side stakeholders, depending on the application

important to seek opinions about priorities from the developers

desirability of the few features or capability

amount of learning that will be created by working on the feature

extent to which risk is reduced by developing the feature

any changes in the relative cost of the feature over time

Teach at three options

Many techniques, there are limitations of formal approaches and specific approaches applied

team should generally be given some latitude in sequencing work into sprints

many reasons for working slightly out of order

An effective product owner is aware of these situations and works with the team to determine their appropriate application

Primary goal: is to bring the vision to life in the best possible way—to develop a product that benefits the customer/user and the organization creating it

successful release management relies on an evolving and improving understanding of user or customer needs

release management consists of

planning takes place at different levels in Scrum: Product, release, sprint, and day

release planning is spread throughout a project, not just early on

Plans in Scrum are dynamic and change as more information about the customer needs and the product being developed becomes available

release planning activities are carried out by the Scrum team often with the help of stakeholders

product owner ensures that the necessary release management activities

quality is defined in the definition of done. It is no longer a variable but fixed

quality compromises lead to technical debt, the software becomes brittle and expensive to extend and maintain

short release cycles and frequent software updates require high quality

product increments should be released to target customers early and frequently instead of delivering the finished product in one go

early and frequent releases allow incorporating feedback from customers and users, creating a product that meets the needs of its use

defined by the amount of effort earned by the team per sprint

only items delivered according to the definition of done contribute to the velocity

best observed / measured empirically

can help the team optimize its velocity

simple report that creates transparency about the project progress relating time and the effort remaining in the product backlog

release burndown chart looks at the past sprints and projects their velocity into the future

no substitute for attending the sprint review meeting to fully understand the project progress and for engaging in dialogue with the Scrum team.

can help forecast the future

release plan is a rough forecast, not a commitment and certainly no guarantee

no substitute for a project plan; it contains less detail and is updated in each sprint

A traditional project plan no longer exists in Scrum

What is it