As more organizations transition to Agile, one of the obstacles they have to overcome is proper estimation techniques in the new methodology. This session presented by Panayiotis “Takis” Melas, PMP, CSM, SSM, SPC, Sr. Consultant/Agile Coach for MI-GSO | PCUBED, covered the core concepts of Agile estimation, and discussed recommendations and pitfalls in breaking down the work segments and estimating the work to be performed, unlocking one of the most valuable components of the Agile methodology. @MIGSOPCUBED_off

1. PMI Houston 2019
Conference & Expo
June 3-4, 2019
NRG Park

2. Getty Images/iStockphoto

3. Introduction
• Panayiotis “Takis” Melas
• Senior Consultant & Agile Practice Lead
• 16+ years IT Project/Program Manager in various organizations,
including Transportation, Manufacturing and Oil/Gas
• 10+ years as a Certified Scrum Master
• Certifications include:
• PMP – Project Management Professional
• CSM – Certified Scrum Master
• SA – SAFe Agile Practitioner
• SSM – SAFe Scrum Master
• SPC – SAFe Program Consultant
• https://www.linkedin.com/in/panayiotismelas/

4. Presentation topic & agenda
• Agile methodology adoption has increased rapidly in recent years
• The adoption of the Agile methodology requires a shift in the thought process
• A common area that teams struggle is to shift to an Agile effort estimation
• Old habits, coupled with incomplete understanding of the new process, result in frustration
• This presentation will discuss:
• High level review of Agile estimation content
• Work breakdown stages
• Agile estimation tools & techniques
• Estimation pitfalls (do’s-don’ts)
• High level forecasting
• Inversing the triple constraint

6. Why adopt Agile
• Incremental, iterative approach
• Frequent collaboration and prioritization
• Highest value items are addressed first
• Full alignment with the client expectations
• Reduced rework and delays
• Relentless improvement through retrospectives
• Each phase completes before the next one begins
• Full requirements gathered in the beginning
• Scope and effort are resistant to change
• Limits collaboration, as each phase is siloed
• Misalignment between the client vision and the end
product
Requirements
Gathering
Technical
Design
Development
Testing
Deployment
Vision
Sprint 1 Sprint 2 Sprint 3
Backlog

7.  Variable
Fixed 
Inverse Triple Constraint
• Waterfall method is scope based
• Cost and Time and derivatives of the Scope
• Resourcing and Scheduling can only be defined once
the Scope is finalized
• Scope is considered a Fixed constraint where Cost and
Time are Variable
• This is described as “bringing the people to the work”
• Agile method is value priority based
• To Cost and Time are Fixed, utilizing Timeboxes to
prioritize the work
• The Scope is not fixed, but flexible based on priority
and expected value
• This is described as “bringing the work to the people”
Scope
Scope
Cost Time
TimeCost
People
Work
Work
People

8. Scrum Agile Framework

10. Cone of Uncertainty
Allows the detailed design and effort estimation of the User Stories based on the highest priority
• High Priority User Stories are
fully defined
• Effort estimates are
determined
• Capacity and work allocation
are aligned
• Minimum variance is expected
• User Stories of lower priority
• Estimated at relative User Story
points
• No significant detail design or
effort estimates are completed
• Effort estimates are at a greater
variance range
• User Stories of Medium priority
• Estimated at relative User Story
points
• Some initial design
considerations are made
• Estimates are at a relative low
variance range
Variance
Range

11. Cone of Uncertainty cont’d
• As time progresses, the eye of the Cone gets closer to the next set of prioritized user stories
• The next set of effort is then better defined and the variance range is reduced
Variance
Range
Variance
Reduction
• User Stories of the next highest
priority
• As the Sprints approach the eye
of the funnel, they are better
defined
• Variance Range is reduced
• User Stories of the next lower
priority.
• As the progress, some initial
design considerations are made
• Although some variability still
exists, it is lower than before

12. Work Breakdown Stages
Theme /
Value
Stream
Epic/
Feature
User Story
Task
• Strategic intent
• Typically provided by Executives
• It can span over several Releases
• Composed by a number of Epics
• Example: “Increase sales by 25% in 2019”
• Solution intent
• Typically defined by Product Managers
• Contained within a Release (Epic) or a Program Increment (Feature)
• Composed by a number of User Stories
• Example: “provide customer with the ability to make online purchases”
• Function intent
• Defined by the Product Managers in collaboration with the Project Team
• Contained within a Sprint
• Composed by a number of Tasks
• Example: “As a customer, I want the ability to enter my CC information on the site, in
order to complete a purchase”
• Action intent, granular level
• Defined by the Project Team in collaboration with the PO
• Should span hours, no more than 1 day
• Example: “Create a label reading ‘Enter your CC# here’”

13. User Story vs. Tasks
User Stories
• Defined during Sprint 0
• User Stories are placed in the Backlog, then
prioritized for placement in Sprints
• Provided by the PO, collaboratively with the Project
Team
• Should contain a proper statement and Acceptance
Criteria
• Should allow flexibility, for the project team to
determine the best method
• Should not be modified mid-Sprint
• Typically estimated in Points
Tasks
• Defined Sprint Planning ceremony
• Identified only for the User Stories committed to
the next Sprint
• Identified by the Project Team, collaboratively with
the PO
• Should address the User Story statement and
Acceptance Criteria
• Can be adjusted/modified, for best alignment with
the User Story
• Can be adjusted during the Sprint
• Typically estimated in Hours
Tasks can be used in the transition of the team to Agile. Teams that have reached full maturity often do away with Tasks, and
focus on the User Story as a concept

15. User Story Points
2
5
8
21
13
• A numerical value assigned to each User Story
• Typically determined during Sprint 0 and can be revised during
Backlog Refinement
• The User Story points should not be adjusted mid-Sprint
• Upcoming Sprint User Story points can be adjusted in the Sprint
planning/Backlog refinement sessions
• The User Story points are based on relative sizing
• Points are based on the assumption that not a lot of detail is known
of the User Stories
• An example is a comparison between buildings, where the specific
size can not be determined
1

16. Agile Poker Cards
• Agile planning is usually conducted with the aid of a set of Agile Poker Cards
• Each Team Member has deck of cards (except the SM and the PO)
• Card numbers are based on a modified Fibonacci sequence (1,2,3,5,8,13,20,40,100,?)
• The deck includes a set of wild cards, as follows:
• Coffee cup: request for a break
• Question mark (?): Unsure of an estimate, might need additional discussion
• Infinity symbol (∞): Story too big to estimate, needs to be broken down further

17. Agile Planning Poker
• Process to find consensus on the User Story points
• The voting includes all the Project team members, except for the Scrum Master and the Product Owner.
• Optional attendees (SMEs, Stakeholders) are also excluded from voting
• The process starts with the team agreeing on one or more User Stories that equal 1 Story point
• Story Point 1 means the User Story can be completed (define, develop, test) in about half a day
• Team votes on each User Story size, compared to the baseline User Story of 1 point
• The voting is done by each team member presenting their cards at the same time
• This is done to avoid “anchoring” where one member’s vote is influenced by another

18. Agile Planning Poker
• Once all cards are revealed, a discussion is needed to find consensus between the team, and agreement on
the final User Story point value
• If agreement can not be reached, the Story can be “tabled” for later discussion
• Note: Avoid trying to associate Points with Hours. Points are based on a relative grading system
• Once the Story points is agreed upon, the Scrum Master logs that in the Backlog and moves on to the next
Story
• If a User Story is rated at 13 points or above, it should be reconsidered for further breakdown, as it will
approach the team capacity limits (for a typical 2-week sprint)
Appropriate size
1 2 3 5 8 13 20 40 100
Too large, or not granular enough

19. Story Points vs. Hours
Story Points
• Used for User Stories, Features & Epics
• Used for high level estimation
• Relative comparison based
• Used for overall team Sprint Capacity
& Velocity tracking
• Should not be modified while Sprint is
in-flight
Hours
• Used for Tasks
• Used for granular estimation of work
• Work/effort based
• Used for daily work completed
tracking
• Can be modified (within limits) while
Sprint is ongoing

20. Using Apples to make Orange Juice
1. Different teams should not assume same
capacity
2. It is NOT advisable to re-estimate User
Stories mid-Sprint. Estimation adjustments
can be identified and addressed during the
Sprint reviews, for future Sprints
3. User Story points should not be equated to
hours. This implies that they have been
fully defined, which is a waterfall approach
1
2
3

22. • The amount of work that can be expected to be delivered by the team within a Sprint
• It creates a baseline forecast for the Sprints
• A common method for new teams is to assign 1 User Story point per FTE (Full Time Employee), per day
• Deduct 1 point per week, for activities that are not User Story related
• PTE (Part Time Employee) allocation can be adjusted based on the above
• The sum of all the team points indicates the Sprint Team Capacity
• Sprint Team Capacity can be used to calculate the number of Sprints (Forecasting)
• Should be adjusted at the Sprint retrospective as needed, based on the Team Sprint Velocity
• Do NOT forget to adjust the Capacity points for vacation, holiday, sick time, etc.
Team Capacity

23. Sprint Velocity
• Reflects the amount of work the team was able to deliver within a Sprint
• It represents the “Actual”, where Team Capacity is the “Planned”
• Estimated during each Sprint Planning session, based on the Team estimated capacity for that Sprint
• Reviewed during each Sprint Retrospective to increase the Team Capacity calculation
• It is reflected in the Project Burndown (or Burnup) Chart

24. Forecasting
• Occurs during Sprint 0, but gets refined/validated throughout the project
• Early forecasting can be completed once
• The Initial Project Backlog has been completed
• The Story Points have been determined and summed up
• The Summary of the points reflects the total of the work planned to be completed
• Forecasting is done by dividing the Points Sum by the Team Capacity
• Sum of Story Points / Team Capacity = Number of Sprints
• This method implies that most of the User Stories have been defined
• The Sprint count can be further adjusted to allow activities such as End-to-End UAT, Deployment, etc.
• Some variance can be expected to the forecast, typically due to:
• Initial estimates require adjustment (team new to estimation or too much ambiguity)
• Some of the scope was not defined during initial estimation
• Scope adjustments in-flight

26. Best Practices
• Allow enough planning time to properly identify and define the User Stories in the project backlog
• Properly prioritize the User Stories to allow the team to focus on the highest priority items
• Plan at least one Sprint ahead
• Review the User Stories with the team, to ensure full understanding
• Ensure commitment of the team to the User Stories selected for a specific Sprint
• Ensure the project team properly identifies and estimates the tasks, only for the User Stories committed to
the upcoming Sprint
• Do not pursue the completion of Tasks single-mindedly. Tasks can be revised to ensure the User Story intent
is fulfilled
• Do not try to equate Points to hours. It serves no value, and it removes some of the benefits of the Agile
process
• Use the Retrospectives to discuss variability in estimates, capacity, etc. for ongoing improvement
• Preserve variability; Change is not the exception, but the rule in Agile.

27. Maturity Process: Shu-Ha-Ri
Imitate Assimilate Innovate
Break the Rule – Practitioner
Practitioners have a good
understanding of the methodology
and can now introduce elements
that are better aligned with their or
their organizations’ needs. It is
critical that the core concepts
remain unaltered
Obey the rule – Apprentice
Practitioners follow the model
exactly. Studying and exploration of
the concepts are important, to gain
understanding of the reasoning
being the required actions
Be the Rule – Master
Practitioners have reached a level
of maturity/mastery of the
methodology. The continuous
leaning process allows for
expansion of the model, allowing
constant improvement of the
model

28. About PCU3ED – Who We Are
We lead our field
With over 25 years’ experience, providing access to over 1300+
consultants across 30+ locations globally, we are the world’s
largest global program and project management consultancy.
We have become the trusted delivery partner of the most
recognizable brands in Aeronautics, Defense, Automotive,
Transport, Financial Services, and Energy as well as government
organizations, helping them convert their big ideas to reality.
1300+
CON SULTAN T S
Y EARS’ E XP E RIE N CE
25+
LOCAT ION S WORLDWID E
30+

29. About PCU3ED – What We Do
Capability Development
EVOLVE client by strengthening PPM maturity
to ensure effective delivery capabilities of
programs and projects.
Innovation & Portfolio
Management
GUIDE in selecting the right ideas, investing
in the right projects, and delivering
effectively to realize benefits.
Project & Program
Delivery
MANAGE programs and projects
successfully throughout the lifecycle
and across all areas.
Managing Change
Enabling business transformation
through delivery of sustainable
CHANGE.
1 2
3 4

30. Questions?
?
?