4. EMPIRICAL PROCESS
CONTROL
Agile is based on empirical control, through
transparency, inspection and adaptation. The best
processes are emerging while doing, and only
retrospectively it is possible to recognize successful
adaptations from non successful ones.
5. PULL PRINCIPLE
Agile approaches are based on pull principle which
allows self-organizing teams to pull in work and
knowledge as needed in order to deliver value to
the customer.
10. SCRUM MASTER
RESPONSIBILITIES
The PROCESS OWNER
Helps the team do its best work
Team level coach
Facilitates communication
Acts as a change agent
11. THE DELIVERY TEAM
Build the thing RIGHT
Made up of whomever is needed to complete the work
Decides HOW to build it
Commit to the Sprint
Own the estimates and tasks
Plan their own work (tasks, dependencies)
15. VISION
Vision Feeds Scope and Priorities
Visioning exercise should be held with all people who need to
buy in to a common vision of the product and/or strategic
direction
Elevator Statement
Design the Product Box
Press Release
18. ROADMAP
Emphasizing the setting of high-level objectives, aligned to
goals around value-delivery
Can be used to define critical dates
Set high-level themes and direction
Should indicate planned evolution over time
19. RELEASE PLANNING
Description
Team to make a “soft” commitment to the completion of a set of the
highest ranked product backlog items for the upcoming release
Synchronize the team on the objectives of the Release and the
opportunity to see the bigger picture
Should be done face-to-face
Likely that the stories will be further refined and may be split into
smaller (value-focused) stories, AC may be modified, and additional
stories may be created
This event may last up to 2 days
20. RELEASE PLANNING
AGENDA
Opening
Product Vision / Roadmap
Review
Architecture Review
Release Name & Theme
Review Velocity
Review Release Schedule &
Iterations
Issues and Concerns
Definition of Done Review /
Modifications
Review Stories in
Consideration
Review Story
Provide High-level Estimates
Split Story (if necessary)
Validate Acceptance Criteria
Identify Issues & Concerns
Identify Dependencies &
Assumptions
Sequences Stories Across
Iterations
Team Commitment
Communication / Logistics
Plan
Close / Mini-retro
21. RELEASE PLANNING
OUTCOMES
A release plan with team-based
understanding of priorities
A best-guess sequence for story mappings
to iterations
High-level story estimates
Issues, risks, dependencies, concerns to be
monitored throughout the Release
23. PRODUCT BACKLOG
What is it?
• Is the ranked list of all the features and functions to be built
into the system and all the defects to be fixed. At its most
basic it is all the work to be done by the delivery team on
the system.
What’s in it?
• Contains features, requirements, user stories, as well as
defects. These items describe the system to be developed
and they comprise work to be planned and delivered.
• Product Backlog Items (PBIs) that cannot be delivered in
one iteration are called epics.
24. PRODUCT BACKLOG
Who owns it?
• The Product Owner owns the backlog. The PO owns all
decisions about content and ranking.
Who Contributes to it?
• Stakeholders contribute their ideas and needs about what
the system should do.
• The Delivery Team contributes technical stories as well as
estimates.
25. RANK FOR VALUE
Goal of an Agile project is to deliver value incrementally.
Product Backlog must be ranked for value.
Consider value in terms of:
Stakeholder and User Value
• Include the System itself as a stakeholder, whose primary interest is its
own health
Strategy Value
• Does a PBI further the product vision or corporate strategy.
Competition Value
• Can a PBI alter the competitive landscape?
Feedback and Learning
• Early feedback from stakeholders. Technical learning, validating
solutions.
27. USER STORIES
User stories are written in everyday language that describe the
interaction between the user and the system, focusing on the
value gained. It is not a highly documented requirement, but
rather a conversation to collaborate on the topic.
A user story should fit onto a 3” x 5” card and will contain 3
parts: the title, the description and the acceptance criteria (AC).
If the title and description don’t fit, then you should revisit the
user story.
As a [user role/who] I want [goal/what], so I can [reason/why]
28. WHO
The who is the “who” who wants the functionality and who
benefits from it. Typically this is a role or persona.
Avoid “As a user…” this is too vague or too general. Use roles to
help the team imagine who they are building the software for.
Helps create a relationship between the team and the “who”.
29. WHAT
This specifies the need, feature or functionality that is desired
by the who. This is what will be built into the software or
service.
Should be clear, so that the team knows what to design and
build.
30. WHY
Specifies the value for the who and is the primary purpose for
delivery.
It is important to help teams design solutions that meet the
real needs of the users and customers.
The “why” is critical as we focus on value driven work . The
“why” keeps the value up front, helping the PO with ranking.
The team needs to understand the “why”, then come up with
the delivery ideas.
If there is no “why”, you most likely have a story with no
value!
31. THE 3 C’S
3 C’s indicate the 3 elements of a user story: Card, Conversation
and Confirmation
Card
• Captures the general idea and is a promise for conversation
Conversation
• Through conversation, the PO and delivery team develop shared
understanding of the goals for functionality as well as constraints.
This should be the whole team participating.
Confirmation
• Well defined user story is testable. AC are the conditions of
satisfaction and acceptance for the story.
32. REFINEMENT SESSIONS
Purpose: To provide input regarding clarity, dependencies, risks,
assumptions, acceptance criteria (AC), and high level estimates in
order to inform the prioritization and on-going maintenance of the
Product Backlog.
Attendees: PO, Delivery Team, Subject Matter Experts (SME),
Stakeholders (if needed)
Outcomes:
Stories have been clarified with any relevant information.
High-level implementation estimates have been provided by the
Delivery Team that will implement the story.
The PO is equipped with information to help with prioritization
decisions.
33. REFINEMENT
DESCRIPTION
A backlog refinement session is intended to provided the PO with
information to keep the Product Backlog healthy.
This on-going session provides synchronization points with the
delivery team to ensure that the stories are understood and in good
standing to be brought into Sprint Planning.
This synchronization ensures that estimates are provided, stories are
clarified and that the PO has enough information to prioritize stories
on an on-going basis.
The whole team should be involved in a backlog refinement session.
Remember to consider your Backlog Refinement sessions when
calculating your team capacity. A general rule of thumb is to reserve
approximately 10% - 15% of capacity for each team member.
Any specialists or SME(s) that are needed for a specific story should
also attend.
34. BREAKING DOWN STORIES
The team helps with the work, but the more the PO can own story
breakdown, the more she can ensure meaningful feedback and valuable
stories.
INVEST in good stories
Independent, Negotiable, Valuable, Estimable, Sized Appropriately,
Testable
Vertical Slices rather than Horizontal layers
36. RANKING THE BACKLOG
Prioritization Attributes
User/stakeholder value
Competition value
Strategy value
Revenue value
Risk
Kano Analysis
Story Mapping
Stack – rank
#1, #2, #3, #n…
37. SPRINT PLANNING
What is it?
PO’s vision for the sprint
Describes the highest priority features to the team
Determines the work for the upcoming sprint.
Items are taken off of the product backlog according to priority and
broken down into manageable tasks.
Who Attends?
Product Owner
Scrum Master
Delivery Team
Outputs
A sprint goal
A sprint backlog (includes the list of tasks necessary to delivering
the product backlog items
38. SPRINT REVIEW / DEMO
What is it?
The Scrum team demonstrates what they accomplished during the
sprint
Very informal
Natural result of the sprint
PO accepts or rejects each product backlog item*
Stakeholders/business and PO provide feedback
Who Attends?
Delivery team
Scrum Master
Product Owner
Customers
Stakeholders
Outputs
Accepted work for the sprint
39. RETROSPECTIVE
What is it?
A retrospective is an opportunity to learn and improve. It is time
set aside – outside of day-to-day routine – to reflect on past events
and behaviors.
Who Attends?
Product Owner
Scrum Master
Dev Team
Outputs
Top Items to improve for the next sprint
Action Items that come out of the meeting
40. DAILY SCRUM
What is it?
Daily meeting held by the team
Not a status or a problem solving meeting
The team reports to each other on what they accomplish
Who Attends?
Product Owner
Scrum Master
Dev Team
Other(s) outside of the Dev team can attend
Outputs
None unless there are roadblocks that the Scrum Master needs to
help remove
41. CHIEF PRODUCT OWNER
This role is the Product Owner (PO) of the whole product.
The CPO is focused on the strategy of the product and own a shared
product vision for the entire product.
The individual team PO will also have a shared product vision that will
ultimately align with the overall product vision.
The CPO owns the single product-level backlog and provides guidance to
the group of PO’s on the Scrum Team(s) that will complete the effort.
The CPO will use the product-level backlog to coordinate the work through
sub-backlogs, through the individual team PO.
This role is filled by a single person not a committee.
This role requires full time focus and commitment to a single product.
The CPO will facilitate collaborative decision making as well as having the
final say if a decision cannot be reached (handled through sessions such as
the Scrum of Scrums which the CPO will own).
Write down on stickies provided and post on the board
What does it mean to “do” Agile or “be” agile?
Is it different type of work?
Drafted in 2001
Representatives from Extreme Programming, SCRUM, DSDM, etc…
There are 12 principles – take a look at the AgileManifesto.org
Process owner – expert in scrum, guides team to best practices
Best work – by protecting the team from outside distractions, encouraging collaboration, inspecting and adapting based on metrics and behaviors
Coaching team on best practices and process
Whomever is needed – made up of 7-9 (ideally) people, QA, BA, DBA, Dev, Report Writer, etc.
Team is cross-functional
Focusing on Scrum since majority of our teams employ scrum
Deliver incrementally – value to market sooner, faster feedback, pivot quick based on new needs, market changes, technology adjustments
The backlog must constantly evolve, as we learn by building small increments
To reduce waste, we evolve the backlog just in time. We might identify most epics for a product, but we elaborate detail only on the highest ranked items.
Highest ranked should be small enough to fit into an iteration. Items slated for later might be larger, until it is time to make them smaller.
The PO constantly prepares the next items for the next planning window.
US is adapted from XP
Independent – Dependencies make sequencing difficult; simplify by avoiding them where possible
Negotiable – Stories are not contracts. Leave room for creativity to bring better solutions
Valuable – All stories should be written to express the value to users and customers (not developers)
Estimable – Your team will tell you if they need more information
Sized Appropriately – For the level planning; small for iteration planning
Testable – The ideal is a binary test result: coded properly or not, done or not
Vertical slices
Rather than beginning with the “data model” begin by creating the ability to create a profile. Throughout the story the team can build the user table and the account table as well as the UI
Research vs. Action
Spike vs. Implementation
Manual vs. Automated
Buy vs. Build
Batch vs. Individual
Single User vs. Multi-User
Simple vs. Complex
Static vs. Dynamic
Slower vs. Faster
Less vs. More
* - PO should be working closely with the team during the sprint so that there are no surprises. Could be approving/rejecting during the sprint
Stakeholders – allows the team to interface with the customer to receive real time feedback on what is being delivered. Also allows the stakeholders to work with the team regarding priorities, value…be a part of the team.
Feedback loops – why we do iterative development
Recommendation is to have single PO unless the product is growing, has more features, more teams to develop it or too big for 1 person
The initial product owner should be in charge of the overall product, take care of the product strategy (High level strategy) and roadmap, and manage the stakeholders, but still be involved in managing the product backlog and making prioritisation decisions. The feature and component owners manage their assets: they capture new ideas and requirements, test them using feedback and data, and collaborate with the teams developing the features and components. The following picture illustrates this approach.
A common technique to do this is unbundling a feature and releasing it as a separate product—like Facebook did with the Messenger app in 2004. This reduces the scope of the original product and it creates a brand-new one, managed by a new product owner and developed by its own team(s).
Another technique is creating product variants—think of iPod shuffle and iPod Touch, for example. Applying this technique avoids feature bloat of the original product; and similarly, to unbundling, it introduces new offerings that are looked after by their own product owners and built by their own teams, as the picture below illustrates.
Splitting product responsibilities along the strategic-tactical dimension works well if a tight integration of strategic and tactical decisions is not required. This is typically the case when the product has entered maturity: it is now incrementally enhanced to defend market share and maximise its business benefits; bigger changes are unlikely to occur—unless you decide to extend its life cycle, for instance, by taking to a new market or segment.
If you use this scaling option at an earlier life cycle stage, then you face the risk of strategic decisions not effectively guiding tactical ones, as well as tactical insights, such as user feedback on specific features or a slower than anticipated development progress, not informing the strategic decisions, particularly when several people take on tactical duties and / or the individuals responsible for strategic and tactical decisions don’t work together very closely.