2 b agile domains

Agile Domains of Practice
Scrumstudy Agile Master Certified (SAMC™)

Domains of Agile Practices
Domain A: Value-Driven Delivery
Domain B: Adaptive Planning
Domain C: Team Performance Practices
Domain D : Agile Tools & Artifacts
Domain E: Participatory Decision Making
Domain F: Stakeholder Engagement
Domain G: Continuous Improvement

Domain A: Value-Driven Delivery
To provide value-driven delivery, it is important to:
• understand what adds value to the customer
• reduce risks that can potentially reduce the value if they occur
• implement the plan that has been formulated based on the priorities
determined
Practices for Value-Driven Delivery
There are five practices that accompany this domain, each with its own tools,
techniques, knowledge, and skills:
• Assessing Value
• Planning Value
• Delivering Value
• Confirming Value
• Tracking & Reporting Value

Value-based prioritization
• Agile Business Value
• Return on investment –ROI
• Net present value – NPV
• Internal rate of return – IRR
• Compliance
• Customer-valued prioritization
• Minimally marketable feature –MMF
• Relative prioritization/ranking

 High degree of customer & developer interaction
 Highly-skilled teams producing frequent iterations
 Right-sized, just-enough, and just-in-time process
Adaptability or Flexibility
High-Performance Teams
Iterative Development
Customer Interaction
• Business Value
• ROI, NPV, ROA
• Trust, Loyalty,
Relationships
• Market responsive
• Business agility
• Customer sensitive
• Leadership
• Empowerment, trust
• Coaching, mentoring
• Early market feedback
• Experimentation
• Sense and response
Value-based prioritization

 A major principle of Agile Methods is creating value
 ROI is the measure of value within Agile Methods
 There are several closely related ROI measures
Type
Costs
Benefits
Breakeven
B/CR
ROI
NPV
Example
Total amount of money spent on agile methods
Total amount of money gained from using agile methods
Point when the benefits of using agile methods exceed the costs
Ratio of agile methods benefits to costs of using agile methods
Ratio of adjusted agile methods benefits to costs of using them
Present value of agile methods benefits that result from their use
1. Assessing Value

Agile return on investment (ROI)
• Return of investment(ROI)when used for project justification,
assesses the expected net income to be gained from a project.
• It is calculated by deducting the expected costs or investment of a
project from its expected revenue and then dividing this(net profit)by
the expected costs in order to get a return rate.
• Other Factors such as inflation and interest rates on borrowed
money may be factored into ROI calculations.

ROI
Most basic assessment of the reasons to
do a project
Term is often used generically to mean
any financial analysis
Usefulness of ROI
ROI fails to consider the time-value of
money
A dollar today is worth more than a dollar a year
from now

COST : Total amount of money spent on Agile Project
Includes training, coaching, automated tools, etc.
Includes the development effort of the project
BENEFIT : Total amount of money gained from Agile project
Includes economic benefit from using new system
Includes maintenance rework savings
BENEFITS/COST RATIO
Ratio of total benefits to total costs of Agile project
Includes development, maintenance, and business
Benefits should be larger than all costs
RETURN ON INVESTMENT (ROI)
Ratio of adjusted benefits to costs of Agile project
Benefits are adjusted downward using total costs
Benefits should be larger than costs
ROI

Formula with Example of ROI
ROI Formula:
ROI=(Project Revenue-Project Cost)/Project cost
Example: the ROI for a project that will cost $125,000 to
develop, with expected financial benefits at $300,000 is
calculate as follows:
Solution: ROI=($300,000-$125,000)/$125,000=1.4
Therefore, the ROI is 1.4 times the investment(or 140%)

Net Present Value #1
Net Present Value : Discounted benefits of using Agile methodology
Future benefits are discounted due to inflation
Minimally, future benefits should exceed all costs

Agile net present value (NPV)
 The difference between the present value of the future cash flows
from an investment and the amount of investment. Present value of
the expected cash flows is computed by discounting them at the
required rate of return.
 The net present value (NPV) or net present worth (NPW) of a time
series of cash flows, both incoming and outgoing, is defined as the
sum of the present values (PVs) of the individual cash flows of the
same entity.
 The NPV of a sequence of cash flows takes as input the cash flows
and a discount rate or discount curve and outputs a price; the
converse process in DCF analysis — taking a sequence of cash
flows and a price as input and inferring as output a discount rate
(the discount rate which would yield the given price as NPV) — is
called the yield and is more widely used in bond trading.

Formula
 Therefore NPV is the sum of all terms,
 Where
 t – the time of the cash flow
 i – the discount rate (the rate of return that could be earned on an
investment in the financial markets with similar risk.); the opportunity
cost of capital
 Rt– the net cash flow i.e. cash inflow – cash outflow, at time t . For
educational purposes, R_0 is commonly placed to the left of the sum
to emphasize its role as (minus) the investment.

Example of NPV
Example: which of the following two project is better to select if NPV is
used as the selection criterion?
 Project A has a NPV of $1,500 and will be completed in 5 years.
 Project B has a NPV of $1,000 and will be completed in 1 year.
Solution: Project A, since its NPA is higher; the fact that Project B
has a shorter duration than Project A is not considered here,
because time is already accounted for in the NPV calculations
(i.e;due to the fact that it is the current ,not future value that is
being considered in the calculation)

Internal rate of return (IRR)
• The discount rate often used in capital budgeting that
makes the net present value of all cash flows from a
particular project equal to zero.
• Generally speaking, the higher a project's internal rate of
return, the more desirable it is to undertake the project.
• IRR can be used to rank several prospective projects a
firm is considering.
• Assuming all other factors are equal among the various
projects, the project with the highest IRR would probably
be considered the best and undertaken first.

Example of IRR
Example: Based on IRR,which project is most desirable?
 Project A, which has an IRR of 15% and will be
completed in 5 years.
 Project Which has an IIR of 10% and will be completed in
1 year.
Solution: project A, since its IRR is higher; the fact that
project B has a shortest duration than project A is not
considered here because time is already taken into
account in the IRR calculations (i.e.; as with NPV,it is the
current, not future value that is used to determine the
IRR)

2. Planning Value
• Value stream mapping
• Customer-valued prioritization
• Simple schemes
• MoSCoW prioritization scheme
• Monopoly money
• 100-point method
• Kano analysis: Exciters, Satisfiers, Dissatisfiers, Indifferent
• Risk-adjusted backlog
• Relative prioritization/ranking

2. Planning Value
Value Stream Mapping
Value stream mapping is a lean manufacturing technique used to analyze the
flow of materials and information currently required to bring a product or
service to a consumer. At Toyota, where the technique originated, it is known
as “material and information flow mapping”. It can be used in any process
that needs an improvement.”
• The Value Stream is the series of work steps performed to deliver the end
product from concept to deployment
• Purpose: Visualize the workflow from concept to cash
• Value-Added Work
– The discovery, creation and transformation of knowledge into working code,
features and systems that customers use to achieve their goals
• Non Value-Added Work (waste)
– Bottlenecks that create delays or add to calendar time
– Activities that consume resources yet don’t add value to the customer

The process of value stream mapping involve the following steps:
 identifying and categorizing various families of value streams
 mapping the various identified value streams into various process areas and
inventories
 measuring things such as cycle time, value generation time, and waste for the various
value streams
 performing root cause analysis on the areas with the worst ratio of value to non-value-
added activities
2. Planning Value
Value Stream Mapping

2. Planning Value
Customer-valued prioritization
In an Agile project, the Customer is represented by a Product Owner
with responsibilities to:
• Define the features of the product
• Decide on release date and content
• Be responsible for the profitability of the product (ROI)
• Prioritize features according to market value
• Charged with maximizing ROI and managing project risk
• Prioritize features according to market value. Takes inputs from:
• Customer
• Team
• Executives
• Competitors
• Other stakeholders
• Adjust features and priority every iteration, as needed; accept or
reject work results.
• Determines release plan and communicates to all
• Prioritized list of features represented as stories
• Can adjust between iterations as needed

2. Planning Value
MoSCoW vs Epics
• Stories are typically modelled in hierarchies
• Large stories are known as “Epics”
• But – not all of the Epic may be Must Have for a release
EPIC
Must Have Story
Must Have Story
Should Have Story
Should Have Story
Could Have Story
Part of MMF for Release 1
Part of MMF for Release 1
May be in Release 1 – if not part of MMF for Release 2
Might be included in Release 1, might be in Release 2
May be in Release 1 – if not part of MMF for Release 2

2. Planning Value
Risk-adjusted Backlog
 Agile projects are said to be business value and risk driven. This
means that we choose practical bundles of work based on priority
assigned by the business and tackling the remaining high risk items
left in the prioritized feature list (Product Backlog). So if we have
stories with residual risk we would want to move that up the queue
and undertake it as soon as possible.
 Before performing the risk management activities, the Product Backlog
is reviewed, the list of prioritized functional & non-functional
requirements to be implemented & tested successfully before delivery
including changed and new requirements must be reviewed

2. Planning Value
Risk-adjusted Backlog
The process is as follows:
1. The Product Backlog items( product features) is reviewed.
2. Risk identification, analysis & prioritization is performed.
3. Risk response activities are performed by mapping the risks identified unto
the Backlog. This is performed by all team members providing individual
risk scores which are then summed up to identify critical risks.
4. Those parts of the backlog associated with critical risk as work item
candidates are selected
5. The iteration goal is now
derived.

2. Planning Value
Relative prioritization/ranking
• Identify 5-9 (approximately) selection criteria
for what is important in the next release
• Select a baseline theme
• Likely to be included in the next release
• Understood by most team members
• Assess each candidate theme relative to the
baseline theme
Various techniques are available for relative prioritization/ranking of Product Backlog..
Theme Screening

2. Planning Value
Relative prioritization
Theme scoring
• Like theme screening but
selection criteria are weighted
• Need to select a baseline theme
for each criteria
• Avoids compression of a
category
• Each theme is assessed against
the baseline for each selection
criteria

Relative weighting
• Assess the impact of having a story/theme
from 1-9
• Assess impact of NOT having it from 1-9
• Calculate the value of each story or theme
relative to the entire product backlog
• This gives you the relative value of that
story or theme
• Estimate the cost of each story theme
• Calculate the cost of each story or theme
relative to the entire product backlog
• This gives the relative cost of that story or
theme
• Priority is given by (Relative Value ÷
Relative Cost)
2.Planning Value

2. Planning Value
Kano Analysis
Surveying users
1. To assess whether a feature is baseline, linear,or exciting
2. We can sometimes guess or survey a small set of users
(20-30)
3. We ask two questions
• A functional question -How do you feel if a feature is present?
• And a dysfunctional question - How do you feel if that feature
is absent?
3. At conclusion, we include all of the baseline features
4. Some amount of linear features
5. But leaving room for at least a few exciters

2. Planning Value
• Monopoly money involves giving customers play money equal to
the amount of the project budget and asking them to distribute it
among the features that they want to prioritize.
• 100-point method, a method developed by Dean Leffingwell and
Don Widrig, involves giving customers 100 points that can be used
to vote for the features each customer feels are most important.

2. Planning Value
Product Roadmap

Story Maps support the primary intent of user stories, rich discussion –
Jeff Patton
2. Planning Value
Story map

• Wideband Delphi
• Ideal time
• Relative sizing/story points
• Affinity estimating
Time, Budget, and Cost Estimation
Estimating a project involves the following steps:
• Determining the size of the project using the one or more of the different
estimation methods
• Calculating the effort required for the project in terms of hours, days, weeks, and
months based on the capability and availability of the team
• Converting the effort into a schedule after factoring in the various dependencies
and resources required for the project
• Calculating the cost of the project by adding labor and other costs
2. Planning Value
Estimation

• In Agile, we
estimate size, not
duration
• Estimates are
intentionally vague
(in the beginning)
• Common estimate
values include:
– T-shirt sizes
– Scale (1-10)
– Fibonacci sequence
2. Planning Value
Estimation

2. Planning Value
Size Estimate – Derive Duration
Size
Velocity
Calculation
Duration
5000 lbs of
snow
Velocity = 50
lbs per trip
5000/50 = 100
trips
120 story
points
Velocity = 20
Points
120/20 = 6
iterations

Story points
• Story points indicate the size and complexity of a given user story relative
to other stories that are part of the project
• No standard definition of a story point exists.
• Determining the number of story points in each story is subjective.
• Progress is demonstrated by delivering tested, integrated code that
implements a story
• A story should be
• Understandable to customer and developer
• Testable
• Valuable to customer
• Small enough so that the programmer can build half a dozen in an
iteration.
• A story point is a measure of magnitude. It's also a measure of the size of
a user story relative to other user stories.
• Story points enable effort to be estimated without trying to estimate how
long it will take
2. Planning Value
Estimation

Ideal time
• Ideal Time is one of the two main estimating units agile teams use to
concentrate the focus on programming . Ideal Time excludes non-
programming time.
• When a team uses Ideal Time for estimating, they are referring explicitly
to only the programmer time required to get a feature or task done,
compared to other features or tasks. Again, during the first few
iterations, estimate history accumulates, a real velocity emerges, and
Ideal Time can be mapped to real, elapsed time.
• Many teams using Ideal Time have found that their ultimate effort
exceeds initial programmer estimates by 1-2x, and that this stabilizes,
within an acceptable range, over a few iterations.
• For a given team, a known historical ratio of Ideal Time to real time can
be especially valuable in planning releases. A team may quickly look at
the required functionality and provide a high level estimate of 200 ideal
days. If the team's historical ratio of ideal to real is about 2.5, the team
may feel fairly confident in submitting an estimate of 500 project days.
2. Planning Value
Estimation

Affinity estimating
1. Silent relative Sizing - a list of items in the Product Backlog to be sized with a
classification of `smaller’ on one side upto `larger’ on the other side by team
members who will be asked to size each item relative to other items
considering the effort involved in implementing it completely. No consultation
is permitted.
2. Editing the Wall : Members read the Product Backlog items and move them
around as needed in either direction, smaller or larger. Discussions around
design, missing Backlog items, clarifications needed, etc are permitted until
agreement is reached on items from `smaller’ to `larger’
2. Planning Value
Estimation

Affinity estimating
3. Place Items into Relative Sizing Buckets :Once all of the Product Backlog
items have been placed onto the wall and edited, they should now be
placed in size buckets
4. Challenge : Members may now review
the estimating work they have done so
far and “challenge” estimates in terms
of size. The team discuss their reasons
for the size associated with each item
and reach agreement on all of them.
5. Get it into an Electronic Tool : the
information should not be not lost once
the estimating has been completed. The
estimates for Product Backlog management
must be transferred immediately to the electronic tool of choice.
2. Planning Value
Estimation

Wideband Delphi Approach
• Identify user stories
• After stories are identified
– Each developer estimates the points (depending on factor to
use: ideal day of work, or complexity) which is not yet known
to other developers.
– Then share the estimate with other developers.
– If estimates differ, ones with differing views present their
ideas.
• Customer clarifies any issues as they come up.
– Again write the estimates until the differences settle and
everyone comes to an agreement.
– The Goal : converge on a single estimate that can be used for
the story+
• Magnitude should be comparable.
• Posting the story cards on white boards can be helpful for
comparison.
2. Planning Value
Estimation

Bad Project
0
35
70
105
140
175
10/9 10/23 11/6 11/20 12/4 12/18 1/1 1/15 1/29 2/12 2/26
Time
Features
Inventory Started Designed Coded Complete
3. Delivering Value
WIP Limits
 High work-in-process leads to longest lead times
 Low work-in-process greatly reduces lead times
 Results in better customer trust and satisfaction
Good Project
0
48
96
144
192
240
2/10 2/17 2/24 3/2 3/9 3/16
Time
Features
Inventory Started Designed Coded Complete

3. Delivering Value
Incremental Delivery
Deploy
Document
$
Agile Concurrent Development
• Fund incrementally – opt to extend,
redirect or cancel at a very granular level
• Deliver & realize value steadily
• Validate designs with users & customers
• Continuously adapt to risk and change
• Integrate early & often
Waterfall Serial Development
Invest up front, only realize value at end, assuming value proposition hasn’t changed
Test
Code
Design
Analyze
$$$
Analyze
Design
Code
Test
Deploy
Document
Analyze
Design
Code
Test
Deploy
Document
Analyze
Design
Code
Test
Deploy
Document
$ $$

Day1
Day2
Day3
Day4
Day5
Day6
Day7
Day10
Day8
Day9
Day1
Day2
Day3
Day4
Day5
Day6
Day7
Day10
Day8
Day9
Day1
Day2
Day3
Day4
Day5
Day6
Day7
Day10
Day8
Day9
Product Development
Day1
Day2
Day3
Day4
Day5
Day6
Day7
Day10
Day8
Day9
Planning Game
Daily Standup/Scrum
Customer Acceptance
Retrospective
Day1
Day2
Day3
Day4
Day5
Day6
Day7
Day10
Day8
Day9
Day1
Day2
Day3
Day4
Day5
Day6
Day7
Day10
Day8
Day9
Day1
Day2
Day3
Day4
Day5
Day6
Day7
Day10
Day8
Day9
Product Development
Day1
Day2
Day3
Day4
Day5
Day6
Day7
Day10
Day8
Day9
Planning Game
Daily Standup/ScrumRetrospective
Day1
Day2
Day3
Day4
Day5
Day6
Day7
Day10
Day8
Day9
Customer Acceptance
4. Confirming Value
Prototypes, Simulations, IKIWISI

One of many “information radiators,” ie dashboard pieces
• During Agile/SCRUM, progress on tasks are tracked then reported
publicly
• Manage tasks, estimates and burndown charts
5 . Tracking & Reporting Value
EVM – Burn Charts

EVM – Burn Charts

The shaded area shows the total number of features to be built. The
dotted area represents the WIP, and the striped section shows the work
that has been completed.
CFD

Progressive Elaboration
• The concept of progressive elaboration refers specifically to a project
management technique in which the plan for the particular and designated
project is being continuously and constantly modified, detailed, and
improved as newer and more improved as well as more highly detailed
sets of information becomes available to the project management team
and the project management team leader as the project unfolds and
begins taking place.
• As a result, the newly revised project management plan has the distinct
quality of being more accurately drawn up and, in the end, more complete.
• These newly formed plans are derived ultimately from a series of
successive iterations as more and better information is made available to
the project management team.
• Progressive elaboration is a fundamentally important step to the project
management planning process as it can take a sketchy preliminary plan
and refine it.

Progressive Elaboration
• Progressive
Elaboration and
Rolling Wave Planning
are very closely related.
• Rolling wave planning
is a technique
of progressive
elaboration.
• Both are a
characteristic of
projects, meaning that
projects are usually
developed in steps, and
continues by
increments.

Rolling Wave planning
• Rolling Wave Planning is a technique that enables planning for a project as it
unfolds - plan iteratively.
• Rolling Wave Planning plans until there is visibility, implements, and then re-
plans.
• As the project progresses gaining more clarity, plans for the remaining months
occur
• The Rolling Wave Planning technique uses progressive elaboration

The Saga is the strategic vision. It sets out what the business is aiming
for and charts the course for reaching it. Each and every thing done
within a Strategic Scrum, Scrum of Scrums or Programme must be
consistent with this vision and fit easily within the Saga's framework.
Epic is a large user stories with lower priority. It is too big to implement
in a single iteration and therefore they need to be disaggregated into
smaller user stories at some point
Sagas, Themes, Epics
Theme is a set of related user stories that may be combined together
and treated as a single entity for either estimating or release planning

Agile teams plan product construction in
layers
5

PLANNING ONION
 Product planning involves a product owner looking ahead than the
immediate release and planning for the evolution of released system
 Portfolio planning involves the selection of the products that will best
implement a vision established through an organization’s strategic
planning
Multiple Layers of planning

5
Release
How can we release value
incrementally?
What subset of business
objectives will each release
achieve?
What user constituencies will
the release serve?
What general capabilities
(big stories) will the release
offer?
Release Roadmap
Target Customers
Target Personas
Story (Backlog
Item)
What user or stakeholder need will
the story serve?
How will it specifically look and
behave?
How will I determine if it’s
completed?
Story Details
Acceptance Tests
Product
or Project
What business
objectives will the
product fulfill?
Product Goals
Product Charter
Customers
User Personas
Iteration or
Sprint
What specifically will we
build? (user stories)
How will this iteration
move us toward release
objectives?
Iteration Goal
Development or
Construction Tasks

5 Levels of Planning
Daily
Standup
Iteration
Plan
Release
Plan
Product
Roadmap
Product
Vision

Agile Planning
• Agile planning activities for large-scale development efforts
should rely on five levels:
• Product Vision
• Product Roadmap
• Release Plan
• Iteration Plan
• Daily Commitment
• The certainty of undertaking activities addressed in each of
the five levels increases as the planning horizon reduces from
a year, to a quarter, and then to two weeks . Therefore, the
amount of detail addressed, the number of people involved,
and the frequency of planning and design activities can
increase without running the risk of spending money on
features that may not be built or may be built differently.
57

Product Vision
• The broadest picture that a person can paint of the future is the product
vision. In this vision, the product owner explains what an organization or
product should look like after the project finishes, indicating what parts of
the system need to change (establishing priority) and what efforts can be
used to achieve this goal (establishing estimates and commitments).
• The product vision describes a desired state that is six months or more in
the future. Further planning activities will detail the vision, and may even
divert from the vision because the future will bring us a changed
perspective on the market, the product, and the required efforts to make
the vision reality.
• There are several possible structures for a visioning exercise, two of
which are to create an elevator statement or a product box . The principle
of both exercises is to create a statement that describes the future in
terms of desired product features, target customers, and key
differentiators from previous or competitive products

Product #2
• Customers demand more frequent changes, and time-to-market is
measured in weeks or months.
• Thinking of a road towards the final product - a product roadmap is
created and communicated to fellow delivery people.
• The goals for doing so are for the product owner to:
 Communicate the whole
 Determine and communicate when releases are needed
 Determine what functionality is sufficient for each release
 Focus on business value derived from the releases
• The delivery team, on the other hand, will:
 See the whole
 Learn about the steps to realize the vision
 Learn the business priorities
 Provide technical input to the roadmap
 Provide estimates for the projected features

Roadmap #1
• Product roadmaps are a critical part of any product strategy, and a
central tool of every product manager. Roadmaps bridge the gap
between multi-year strategic plans and release/iteration
planning. Thoughtful, consensus-built, up-to-date roadmaps keep
product teams from wandering and deliver on company strategies much
more quickly.
• Agile roadmaps are an underpinning of Business Agility. They provide
the framework for deciding when plans should change, what impact
potential changes will have on related products/releases/objectives, and
act as a collaborative tool for communicating the plan of record.
• Developing a roadmap is a highly collaborative process. A typical
engagement brings together key contributors [product management,
engineering/architects, marketing, professional services] to create the
initial roadmap for a product, and includes a quarterly re-assembly of the
team for updates and review

Roadmap #2
• The creation of the roadmap is largely driven by the product owner in a
single meeting or a series of meetings.
• This can be done through a graphical representation of the releases, or
more formally in a written document outlining dates, contents, and
objectives of the foreseen releases.
• A list of desired features also needs to be built - this is the product
backlog which is a table or spreadsheet of brief product requirements, so
the delivery team can provide estimates for delivery of each feature.
• The success of an agile project depends on the early delivery of the
highest priority features, the list must be prioritized.
• The prioritization of the feature list is the responsibility of the business,
i.e. the product owner.
• Interaction with the delivery teams is required. Without a discussion of
the features it will be hard for the delivery team to produce estimates that
have an acceptable inaccuracy.
61

Product Vision
• What are you trying to accomplish?
• How is that going to benefit the business?
Daily
Standup
Iteration
Plan
Release
Plan
Product
Roadmap
Product
Vision

Product Roadmap
• High level themes for the next few releases
• Shows progress towards strategy
• Lots of “wiggle room”
Daily
Standup
Iteration
Plan
Release
Plan
Product
Roadmap
Product
Vision

A product roadmap is a planned approach that helps with strategic project
planning and communication of that plan with respect to product releases,
functionality listing, etc.
Product roadmap forms an integral part of any product strategy and provides the
framework for plan changes and the impact they would have on the product. It’s
not just about the specific features or functionality of the product, but the long
term product vision/goal of how far one would go with it.
 A product development roadmap
can be as simple as a list of the
main areas of focus, or themes
 As we learn more about our
product, its market, and our ability
to develop the product, the
product roadmap will change.
Product Roadmap

Release Plan
• Goes into next level of detail towards themes
• Sets a common understanding
• A projection, not a commitment
Daily
Standup
Iteration
Plan
Release
Plan
Product
Roadmap
Product
Vision

Why do Release Planning?
• Get everyone on the same page
• Understand what you will likely achieve
• Balance load between the teams

Staying Releasable
• Define what “Done” means for your team
• Make “Done” more stringent over time
• Definition of releasable evolves as you do

A release plan presents a roadmap of how the team intends to achieve
the product vision within the project objectives and constraints identified
in the project data sheet.
 It helps the product owner and the whole team decide how long it
will take before they have a releasable product.
 A release conveys expectations about what is likely to be developed
and in what timeframe.
 A release plan serves as a guidepost toward which the project team
can progress.
Release Plan

Release Planning Meeting
Release Plan
Iteration 1 Iteration 2 Iteration 3 Iteration 4−7
The purpose of release planning is to define the contents of a release or a
specific shippable product increment.
Release Planning

Preparing for Release Planning
• Set themes
• Prepare the backlog
• Understand stories
• Understand the issues
• Identify key dates

Determine
conditions of
satisfaction
Estimate the
user stories Select an iteration
length
Estimate velocity
Prioritize user
stories
Do in any sequence
Select
stories
and a
release
date
Iterate until the
release’s conditions
of satisfaction can
best be met
The team and product owner collaboratively explore the product
owner’s conditions of satisfaction that include scope, schedule, budget,
and quality
Planning a Release

 Velocity is a measure of a team’s rate of progress per iteration.
 It is calculated by summing the number of story points assigned to
each user story that the team completed during the iteration.
Summing up the story points assigned to each user story gives the
velocity. Hence velocity = 5+3+7+5 = 20
The project team completes four stories in one iteration,
Story A – 5, Story B – 3, Story C – 7, Story D – 5. Calculate the
velocity?
Velocity

Iteration 3−4
An Example with Velocity = 14
Iteration 1
Iteration 2
Story A
5
Story B
8
Story E
1
Story A
5
Story B
8
Story E
1
Story C
3
Story D
5
Story F
3
Story G
3
Story H
13
Story I
5
Story J
8
Story C
3
Story D
5
Story F
3
Story G
3
Story H
13
Story I
5
Story J
8

After the Release
• Do a release retrospective
– Success = Shared Understanding of What and How

Iteration Plan
• Define scope as a team
• Define a clear understanding
of “done”
• First level where you actually
commit
Daily
Standup
Iteration
Plan
Release
Plan
Product
Roadmap
Product
Vision
An iteration plan is a low level view of the product where the team takes a more
focused, detailed look at what will be necessary to implement, i.e., only those
user stories, that have been selected for the iteration.

Iteration Plan
Iteration Plan Meeting
SpreadsheetProduct Owner
Analysts
Programmers
Testers
Database Engineers
UI Designers
Post it Note Cards
 An Iteration Plan is created during the Iteration Planning Meeting
 It can be as simple as a spreadsheet or a set of note cards with one
task handwritten on each card
Iteration Planning

Release Plan Iteration Plan
Planning horizon 3-9 months 1-4 weeks
Items in Plan User Stories Tasks
Estimated In Story Points or ideal
days
Ideal hours
 The release plan looks forward through the release of the
product while the iteration plan looks ahead only the length of
one iteration.
 The user stories of a release plan are estimated in story points or
ideal days, the tasks on the iteration plan are estimated in ideal
hours.
Release Plan & Iteration Plan

Daily Standup
• First level of individual commitment
– What did I do yesterday?
– What will I do today?
– What’s blocking me?
Daily
Standup
Iteration
Plan
Release
Plan
Product
Roadmap
Product
Vision

Organizing Requirements into MMF
The MMF (Minimum Marketable Feature) is the smallest set of
functionality that must be realized in order for the customer to perceive
value.
Characterized by the three attributes
– minimum – smallest complete requirement
– marketable - something that is perceived, of itself, as value by the user
– feature – requirement of the product
A release is a collection of MMFs that can be delivered together within the
time frame.

Minimally marketable feature –MMF #1
The smallest set of functionality that must be realized in order for the
customer to perceive value. A “MMF” is characterized by the three
attributes: minimum, marketable, and feature. A feature is something
that is perceived, of itself, as value by the user. “Marketable” means
that it provides significant value to the customer; value may include
revenue generation, cost savings, competitive differentiation, brand-
name projection, or enhanced customer loyalty. A release is a
collection of MMFs that can be delivered together within the time
frame.
• Competitive differentiation
• Revenue generation
• Cost saving
• Brand projection
• Enhanced loyalty

Prioritizing Requirements based on value
81
High Priority Story
High Priority Story
Medium Priority Story
Low Priority Story
High Priority Story
Low Priority Story
High Priority Story
Must Have For Release
MoSCoW Prioritization
Technique
Must Haves - Fundamental to
the projects success
Should Haves - Important but
the projects success does not
rely on these
Could Haves - Can easily be
left out without impacting on the
project
Won't Have - This time round
can be left out this time and
done at a later date

Minimum marketable features-MMF #2
• Within the Agile methodology the teams
will prioritize their backlogs
• The highest-priority items will be included
in the release before the lower-priority
ones.
• For a release we could say that we won’t
release unless we have the top four
stories…
• Agreeing this set of minimum marketable
features (MMF) provides us with an high-
level payload that we can estimate.
High Priority Story
High Priority Story
Low Priority Story
High Priority Story
Low Priority Story
High Priority Story

Domain C. Team Performance
Practices
Adaptive Leadership: refers to adapting a style of leadership based on
specific circumstances and the quality of the team in its formation.
Tuckman Stages of Team Formation: forming, storming, norming, and
performing

Emotional intelligence: refers to the ability to identify, evaluate, and
control the emotions of oneself and other individuals or groups

Build empowered teams: Empowered teams display traits of
being self-organizing and self-directing
Building high-performance teams:
• Restrict team size to 12 or fewer members.
• Create a shared vision for the team to build trust.
• Set realistic goals that are achievable by the team.
• Create a sense of identity for the team to increase loyalty
and support among team members.
• Leaders should be there to provide direction while still letting
the team assume responsibility of the project
Team motivation: refers to the ability of the leader to push the
team to grow from performing passively to performing with
passion.

Team Practices
Team Practices: Activities that teams can use to improve their efficiency.
Daily stand-ups
Daily stand-ups are brief and focused status meetings. Team members
answer three questions during the meeting.:
• What have you worked on since the last meeting?
• What do you intend to work on today?
• Are there any challenges or roadblocks that you are facing?
Conversations related to fixing issues will not be held during the meeting in
order to keep the meeting focused and within its fifteen minute time-box
Coaching and Mentoring: could be at individual level or at a team level or
both.

Brainstorming Techniques
Brainstorming helps Agile teams come up with innovative ideas,
solve problems, and make suggestions for improvement. Teams can
use several methods to brainstorm.
Quiet writing: In this method, members create a list of ideas that
can be shared and discussed with other team members.
Round robin: In this approach, team members take turns sharing
their ideas, which can be improved by other team members.
Free-for-all: In this approach, members spontaneously shout out
their ideas, and other team members can expand on those ideas.
After recording ideas, they need to be sorted, prioritized, and acted
on.
Team Practices

Team Space
88
A key element of Agile projects success is the need for real time, dynamic
communication. This can be achieved by co-locating the team, using low-
tech communication tools that are easy to understand and keep up-to-
date.
The team space must be a:
• Collaborative environment
• Real time, dynamic communication
• Face-to-Face communication
• Safe environment
• Facilitates team decision making and team maturity
• Protects team from external interruptions
• Resource availability
• Developers work environment

Team Space
89
• Team members must be in close proximity to each
other, preferably facing one another
• There must be a centralized team area where most
of the work is done with privacy areas for individual
“heads-down” work or personal time
• Walls should be used to posting notes, displaying
charts, graphs and the results of brainstorming
• Team members must have easy access to whiteboards or charting paper to
collaborate quickly and effectively with team members
• Plenty of room for Daily Stand ups. For some teams it works best to have a “theater
area” where the team can come away from their desks to separate area without
distractions to pay better attention.
• Developers workstations, probably two monitors, and minimal distractions
• A good telecommunication system for distributed team collaboration.
• A good Application Lifecycle Management Tool

Caves and Commons
• The Caves and Commons room arrangement recommended in XP
• The phrase Caves and Commons refers to the creation of two zones in
the room.
• The Commons area is organized to maximize osmotic communication
and information transfer.
• People in the room must be working on the same project. It is perfect
for XP’s single team of up to 12 people programming in pairs.
• The Caves portion of the room is organized to give people a private
place to do e-mail, make phone calls, and take care of their need for
separation

Innovation games #1
• Innovation Games® are serious games that can be used to deliver cost-
effective market research for Agile teams and super-charge the product
planning process. Based on the book oby Luke Hohmann, Innovation
Games® power innovation by enabling you to better understand your
customers
• Innovation games are a special type of activities designed for embracing
the innovation by helping people to collaborate and discuss in a form of
playing a game. These games are useful and interesting, than any traditional
requirement workshop based on reviewing the requirement document
proposal.
• Innovation games are one very clear example of applying the Individuals
and interactions over processes and tools principle.
• In the beginning of the game the team or product manager presents a list
of all the features of interest with the price tags, where price means the cost
of implementing the feature in whichever units. Agile teams typically use
the size estimates in story points or ideal engineering days. The units used
are not important, the only important thing is the approximate relation
between the feature costs, so that it was clear that feature with the price tag
of 100 is a way more difficult, than a feature that costs 10.

Innovation games #2
• All the participants, which ideally include
team members, marketing, sales and real
customers, are given some virtual dollars
that they can spend on buying the features
they like.
• Whatever the concrete method is, in the
end a group of people form a collective
and quantified opinion on the feature
priorities, on what is really important to
them, what is nice to have and what they
could live without.
• This method works well, because it
implicitly forces the participants, who
should always include your customers, to
leave the "we want it all" attitude and
discuss the actual product priorities.

Agile games (collaborative/innovative games): used by teams and
stakeholders to identify issues and agree on solutions.
• Remember the Future: This exercise helps set a vision for the
project and elicit requirements from stakeholders.
• Prune the Product Tree: This brainstorming exercise is conducted
to determine a product’s features and functionality.
• Speedboat: With this exercise, teams and stakeholders identify
benefits and threats from the project.
• Buy a Feature: This exercise is held to prioritize features once they
are finalized.
• Bang-for-the-Buck: This exercise evaluates business value versus
cost.
.

Domain D
Agile Tools & Artifacts

Information Radiator
• The term "information radiator" was introduced in 2000
by Alistair Cockburn An information radiator is any
artifact that conveys project information and is publicly
displayed in the workspace or surroundings.
• Information radiators are typically used to display the
state of work packages, the condition of tests or the
progress of the team. Team members are usually free to
update the information radiator. Some information
radiators may have rules about how they are updated.
95

• Whiteboards, flip charts, poster boards or large electronic displays
can be used as the base media for an information radiator. For new
teams, the best medium is usually a poster board on the wall with
index cards and push pins. The index cards have a small amount of
information on each of them and the push pins allow them to be
moved around.
96

Information radiators help amplify feedback, empower teams and
focus a team on work results. Too many information radiators
become confusing to understand and cumbersome to maintain. If an
information radiator is not being updated it should be reconsidered
and either changed or discarded.

User Story #2
Follow the I.N.V.E.S.T. principle

User stories/Product Backlog
•Requirements which could be a collection
of stories for a software product are
captured as items in a list of “product
backlog” It contains a list of all desired
work on the project .
• Prioritized list of work to be performed on
a product such that the most valuable
items are highest
• Ideally expressed such that each item has
value to the users or customers of the
product
• Anyone can contribute backlog items
• Product Owner is responsible for
prioritization
• Reprioritized at the start of each sprint

User Stories are multi-purpose
Stories are a:
– User’s need
– Product description
– Planning item
– Token for a conversation
– Mechanism for deferring
conversation
* Kent Beck coined the
term user stories in Extreme
Programming Explained 1st
Edition, 1999

Agile customers or product owner prioritize
stories into a backlog
• A collection of stories for a
software product is referred to as
the product backlog
• The backlog is prioritized such
that the most valuable items are
highest

Agile modeling: set of modeling techniques used on Agile projects.

User Story Maps #1
User Story Mapping is an approach to organizing and prioritizing user
stories
• Story Maps make visible the workflow or value chain
• show the relationships of larger stories to their child stories
• help confirm the completeness of your backlog
• provide a useful context for prioritization
• Plan releases in complete and valuable slices of functionality

User Story Mapping for Organizing and
Prioritizing user stories
Story Maps support the primary intent of user stories, rich discussion

User Story Mapping for Organizing and
Prioritizing user stories
Unlike typical user story backlogs, Story
Maps:
– make visible the workflow or
value chain
– show the relationships of larger
stories to their child stories
– help confirm the completeness of
your backlog
– provide a useful context for
prioritization
– Plan releases in complete and
valuable slices of functionality.

User Story Maps #2
• Organize user stories into a map that communicates experience
• By arranging activity and task-centric story cards spatially, we can tell
bigger stories
• Add task-centric stories in under each activity in workflow order left to right
• Overlap user tasks vertically if a user may do one of several tasks at
approximately the same time
• The map shows decomposition and typical flow across the entire system
• Repeated review of the story map with multiple users and subject matter
experts will help test the model for completeness
time
Below each activity, or large
story are the child stories
that make it up

The map shows decomposition and typical
flow across the entire system
Reading the activities across the top of the system helps us understand
end-to-end use of the system
time
Below each activity, or large
story are the child stories that
make it up

Agile Modeling #1
Agile Modeling is a practice-based methodology for Modeling and documentation
of software-based systems. It is intended to be a collection of values, principles,
and practices for Modeling software that can be applied on a software
development project in a more flexible manner than traditional Modeling methods.
Agile Modeling principles include :
 Assume Simplicity
 Embrace Change
 Enabling the Next Effort is Your Secondary Goal
 Incremental Change
 Maximize Stakeholder Investment
 Model With a Purpose
 Multiple Models
 Quality Work
 Rapid Feedback
 Software Is Your Primary Goal
 Travel Light
 Content is More Important Than Representation
 Open and Honest Communication

Agile Modeling #2
Agile Modeling Practices include:
• Active Stakeholder Participation
• Apply the Right Artifact(s)
• Collective Ownership
• Create Several Models in Parallel
• Create Simple Content
• Depict Models Simply and Publicly
• Iterate to Another Artifact
• Model in Small Increments
• Model With Others
• Prove it With Code
• Single Source Information
• Use the Simplest Tools

Agile Modeling #3
Agile Modeling is used when:
• an agile approach to development in general
• a plan to work iteratively and incrementally
• the requirements are uncertain or volatile
• the primary goal is to develop software
• the active stakeholders are supportive and involved
• the development team is in control of its destiny
• the developers are responsible and motivated
• adequate resources are available for the project
 Agile Modeling is meant to be tailored into other, full-fledged
methodologies, enabling you to develop a software process which
truly meets your needs.

Agile Modeling #4
There are various approaches to Modeling
AGILE
Model
Driven
Development
AGILE Feature
Driven Development
UNIFIED PROCESS

Lean Kanban Software
Development
Lean Kanban integrates the use of the visualization methods as prescribed by
Kanban along with the principles of Lean Software Development.
Core Values:
Kaizen: Japanese term used to define continuous improvement. The word is
made up of two parts. “Kai” means an idea for change or an action to rectify
something, and “Zen” simply means “good.”
The Kaizen cycle
Plan: Chalk out a plan to work on areas that need improvement.
Execution: Carry out the changes according to plan.
Observation: Observe the difference in the process after the execution.
Evaluation: Evaluate the results, and see how well it works for the process.
Muda: This is a Japanese term used to refer to any wasteful activity that has no
value
Mura: In Japanese, this term means “unevenness or inconsistency in physical
matter or human spiritual condition.”
Muri: This Japanese word is used for “overburden, unreasonableness or
absurdity.”
Genchi Genbutsu: In Japanese, this means “go and see for yourself.”

Definition of Lean Kanban
Lean Kanban is a set of values and principles that outline how to succeed with
product development, while Kanban is a process tool used for putting these
values and principles into practice. Lean Kanban combines these practices with
process tools to create value from product concept to product delivery.
1. Optimize the whole
2. Eliminate waste
3. Build in quality
4. Learn constantly
5. Engage everyone

Mapping value streams: value stream is a list of steps taken to create
value, both for the customer and the team. Steps to build value stream:
• Define the start and end point for control
• Work item types: (Requirements, Features, Bugs, User stories, Use
cases, Change requests)
• Drawing a card wall
• Demand analysis
• Allocating work based on capacity
• Anatomy of a work item card

Implementing Lean Kanban
Prerequisites
• Reduce batch order size. Without setup reduction in place, order sizes
are not reduced and the process is reduced to batch production.
• Certify your suppliers and channel partners to ensure they adhere to
preset norms and are open to periodic inspection.
• Analyze the current value stream, and identify elements and
components that need to be changed to match the future value stream
map.

Implementing Lean Kanban
• Limit Work in Progress (WIP), and be mindful of the workflow.
• The Product Owner and the development team should meet regularly to
break down user stories into tasks.
• Hold meetings once a week for story planning and estimation.
• The Kanban board can be used instead of an Agile story board; each
work item corresponds to a feature, or user story.
• Schedule 15 minutes each day for a Daily stand-up Meeting.
Either approach is effective for projects of all sizes.

Domain E: Participatory
Decision Making

Soft Skills - Conflict Management
• Conflict in an agile project team is inevitable
• it involves individuals from different
backgrounds and orientations working
together to complete a complex task.
– Conflict over different objectives and
expectations
– Unclear roles and uncertainty about who
has the decision-making authority
– Interpersonal conflicts between people
• A mechanism available to
1. inform the team there is a conflict
2. prevent further changes until this conflict
is resolved
3. Usually this will require a discussion
between the authors of the changes
4. The conflict can then be corrected

Soft Skills - Facilitation methods
A facilitator is someone who makes it
easier for others to communicate while
maintaining a neutral stance
A good facilitator:
• Creates an open environment so others
can make decisions during the
discussions.
• Recognises disruptive behaviour within
a group and does something about it.
• Has no authority.
• Good facilitation means ‘dealing with
attitudes and behaviours that lead to more
effective work.
• It’s not the facilitator’s responsibility to
work on motivating others. Instead, a good
facilitator recognises negative behaviour
and deals with it in a respect way to all
those involved

Participatory Decision Models
A way to involve the team in the decision-making process
Simple voting:
Thumbs up/down/sideways:
Jim Highsmith’s Decision Spectrum:
Fist-of-five voting:

Participatory Models
 Everyone agrees the sprint is doable
 No really…EVERYONE agrees
 Use disagreement and uneasiness in team members to drive out
hidden risks, tasks, and issues
 Drive agreement with a fist of five
 This is the best idea possible
 The only thing wrong with this idea is that it wasn’t mine
 I can support this idea
 I’m uneasy about this and think we need to talk it out
some more
 Let’s continue discussing this idea in the parking lot

Participatory decision models
Team commitment is an important factor in agile software development,
which can be strengthened by giving teams the room to make decisions as
a group. A team facilitator can guide and coach them where appropriate
• Consensus can be a very powerful
model of participatory decision
making when it is considered to be
a “win-win” process and held as
integral to the purpose of the group.
Although it is sometimes abandoned
as being overly complex and time
consuming, consensus decision making,
in itself, opens the process to careful
consideration, listening, and negotiation.
In this context, decisions must be fully understood and agreed to by all
members of the group, and the group holds the process of making a
decision which is in the best interests of everyone.

Participatory decision models
A team in flow aggressively
collaborates to derive
informed decisions.
Together, team members
create participatory
commitment events at the
start and end of each time
box as well as each day.
They take ownership of their
task definitions, task
estimates, and the quality of
the work done, and they
invite the engagement of a
facilitative leader to guide
their collaboration.

Servant-Leadership
Listening
Empathy
Healing
Awareness
Persuasion
Conceptualization
Foresight
Stewardship
Commitment to the growth of people
Building community

Stakeholder: any person or group that has interest in the
project and can negatively or positively impact the project.
Stakeholder Engagement
• Getting the right stakeholders
• Cementing stakeholder involvement
• Actively managing stakeholder interest
• Frequently discussing what “done” looks like
• Showing progress and capabilities
• Frankly discussing estimates and projections

Aligning Stakeholders
Stakeholder Plan
Activities are concurrent
All artifacts are starting-points
Anything can be changed

Wireframes
• Wire Frames are essentially Blueprints for placeholder and
functionality
• They are a basis for discussion and a Communication tool (like Page
Architecture, Mock-Up, Page Schematic)
• Typically wireframes are developed by an information architect,
usability expert, requirements analyst (BA), or designer
• Wireframes are not prototypes, do not convey Brand and are not
final design (e.g. colors, graphics, or fonts)
• They enable communication with clients and stakeholders
• They focus on application functionality
• They help get people thinking and generate requirements and
therefore aid in eliciting functional requirements
• They help getting signo-ff and therefore avoid expensive Change
Requests

Wireframes
Common Wire Frame Tools
• Hand sketch
• Excel
• HTML
• Visio
• Photoshop
• Gliffy
• Axure
Permit Application
Tab 1 Tab 2 Tab 3 Tab 4 Tab 5 Tab 6
Dave SmithContact Person
M2009-000267Application #
Start Date
End Date
15-76SHSystem Code
Monthly Permit
Annual Permit
*
*
Flag Three
Flag One
Flag Two
NewStatus
12/12/2008Date Created
15/12/2008Date Issued
$ 15.00Permit Fee
WinterSeason
A
A Read only for user, Admin can overwrite it
A
B
B
Flags are updated based on start and end date
Customer Information
Uploaded Documents
Drawing004.jpg
Signed application.doc
C
C
Link to download document
E Only visible to Admin
F Link to Customer detail page
PrintCopyCancel
Pay Online
D
D
Only if permit is in approved state
Approve PermitReject Permit
EE
Acme CutomerCustomer
Address 114 – 120 Ave NE
Postal Code T6R-0F4
Customer Code ACME
City Edmotnon
Phone 780-123-4567x369 Fax 780-987-6541
Prov/State Alberta
W - WebIssue Code
WF-103
Drawing005.pdfUpload
Joe SmithApproved by
F

Personas
• Personas determine what a product should do and how it should behave.
They communicate with stakeholders, developers, and other designers.
Furthermore, personas build consensus and commitment to the design
and measure the design’s effectiveness.
• They also contribute to other product related efforts such as marketing
and sales plans
• They describe the target user – his wishes, desires and application-
specific aspects.
• They show the nature and scope of the design problem
• Each persona represents a peer group of users. With a detailed
description of the personas, every member of the project knows the main
users and has a unified view of the target customers
• The advantages of personas are that they allow to unify the picture of the
target user for the project team, which allows for a more fluent
communication
• Personas can also be used as an evaluation tool such as walkthroughs .
As an archetypical figure, personas can guide decisions about product
features, navigation, interactions, and even visual design

Personas

Incorporating Stakeholder
Values

Stakeholder Management
Team Formation & Training
Initiate Program
Iteration 0
Assessment
Business Discovery
Identify
Stakeholders
DefineGoals
&Objectives
Stakeholder
Meetings and
Alignment

Stakeholder Communications
Management
The ideal mode of communication in Agile is face-to-face (F2F)
communication

Domain G. Continuous Improvement

Metrics to improve quality
– Quality is measured by passed tests and customer
acceptance
– Quality is defined by Definition of Done and
Acceptance Criteria
– Defect metrics use in Agile projects
• Number of open defects
• Escaped defects
• Defect Cycle Time
• Defect spill-over
– Test Automation is critical!

Escaped Defects
• Calculation:
– For all releases, find
all defects related to
the release found
after the release date
– Add up all the defects
– Can be captured per
day / week / month /
… or per sprint /
release
0
1
2
3
4
5
6
7
8
9
Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
• Used to measure the quality of delivered
code
Escaped Defects over Time

Defect Cycle Time
• Rapid resolution of defects is important
• Average bug-fix time can also be tracked for
different priority bugs
0
2
4
6
8
10
12
14
16
18
20
1 2 3 4 5 6 7 8 9 10
Hours
Sprint No.
Defect Cycle Time
Desired Threshold

Defect Spill-over
• Resolution of defects for a sprint story within the sprint is
important
• Definition of Done can include a criteria like “No P1 defects”
• We can also tracked whether spilled-over defects are being
closed in the next sprint
0
1
2
3
4
5
6
7
8
9
1 2 3 4 5 6 7 8 9 10
Noofdefects
Sprint No
Defect Spill Over

Test Automation
• Critical factor for regression testing
• Coverage should be as high as possible

What does this CFD say?
Not started
Started
Completed
Too much Work-In-Progress!
Image from MountainGoat Software

Identifying bottlenecks with a CFD
Where is the bottleneck?
In DB Procs – After the widening Analysis phase
1 2 3 4 5 6 7 8 8 10 11 12 13
Day
Image from http://www.soliantconsulting.com

Increase Predictability / Reliability
• Velocity
• Lead Time
• Cycle Time

Failure modes and alternatives
Since Agile operates as a collaborating, self directed team,
chances of failure could be for any of the following reasons”
• Too little attention to breaking development and
implementation into manageable steps.
• Evaluation of proposals driven by initial price rather than
long-term value for money (especially securing delivery of
business benefits).
• Lack of understanding of, and contact with the suppliers of
technology at senior levels in the organization.
• Lack of effective project team integration between clients,
the supplier team and the supply chain

Positive traits that act as a counterbalance against failure modes
• People are good at observing and noticing change.
• People discover new ways to rectify errors and enhance their skills.
• People are open to change and are acceptable to new ideas.
• People take pride in their work and can step beyond their job description while
working on a project.
Strategies to overcome failure modes
• Establish and encourage adopting a standard way of working, while still
including scope for tolerance and forgiveness.
• Create a concrete representation of the final solution.
• Alter or modify an existing design that can act as a framework for the solution
instead of starting from scratch.
• Assign work based on the personality types of different team members.
• Attract and retain the best talent.
• Provide quick and continuous feedback.
Variance and trend analysis: Variance is the measure of how far an actual
outcome is from an expected outcome - Common Cause Variation and special

Leading versus Lagging Measurements: Trend analysis gives project
managers an indication of potential issues before they have cropped up.
Lagging metrics, such as the proportion of budget that has been utilized,
provide insights into things that have already occurred. Leading metrics
provide information about things that may be happening or about to
happen in a project.
Control limits: provide warning signs about problems that may occur.
Calculating velocity and determining a minimum limit, below which a drop
in velocity could cause problems is an example of a control limit. Task
boards are a good tool for team enforcement of control limits, because they
restrict the team from undertaking too many tasks.

Continuous integration: Using continuous integration techniques,
developers commit new and modified code into the code repository
whenever possible mitigating the problem of multiple team members
making changes to obsolete code, ensuring that only the latest code is
worked on avoids any compatibility issues.
Risk-based spike: exercise during which a problem is analyzed. An
isolated experiment is performed to find a solution for a problem. The
problem is eliminated if the experiment is successful. Usually used early on
in projects that are trying to develop new technologies before venturing too
far into project development.
Fast failure: the case when risk cannot be eliminated by any method
indicating that the project would have failed if it were continued. Remaining
funds and resources can be used for other projects.

Problem solving
Step 1- Gathering data: Commonly used methods:
• Triple nickels
• Satisfaction histogram
• Color code dots
Step 2- Generating insights: Commonly used methods:
• Five Whys
• Brainstorming
Step 3 - Deciding what to do: Commonly used methods:
• SMART goals: specific, measurable, attainable, realistic, and timely.
• Circle of questions
• Force Field Analysis

Retrospectives: meetings that happen at the end of each iteration. Team
members share lessons learned so they can be applied during the next
iteration.
Retrospective sessions are typically split into five segments. They are:
1. Setting the stage
ESVP (Explorer, Shopper, Vacationer, and Prisoner): attitudes of
different team members toward the retrospective - whether they want
to explore and discover new ideas (explorer), will listen to others and
identify ideas that they would like to work on (shopper), are not
interested in the retrospective activity but are passive participants
(vacationer), or feel forced to attend the retrospective (prisoner).
2. Gathering data
3. Generating insights
4. Deciding on a course of action
5. Closing the retrospective:
Help, hindered, hypothesis: This activity includes identifying what
helped and hindered the team during the iteration, and the team
creates a hypothesis for possible solutions.

2 b agile domains

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie 2 b agile domains

Ähnlich wie 2 b agile domains (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

2 b agile domains