Presentation on Agile Estimation from Agile:MK user group on 7 October 2019 by Rien Sach and John Donoghue https://www.meetup.com/Agile-MK-Agile-User-Group/events/262193686/

1. So When Will It Be Done?
John Donoghue and Rien Sach
Agile:MK – Oct 2019

2. Areas to cover
• “Agile estimating”
• The realistic compromise
• The Iron Triangle (and that important middle bit)
– Fixing Date
– Fixing Scope
• REAR

3. • First question – what is agile estimating?
– What does “by the book” mean?
– What do we consider when making an estimate?
– How do we measure/record estimates?
– How do we communicate the outcome of our
refinement/estimation?
Agile Estimating

4. • Starts with a prioritised backlog
• Items are refined and estimated in priority order
• More attention is given to the higher priority items
• Anticipated that you’ll review and refine items as they
progress up the backlog
• Likely re-estimate backlog items as things become clearer
Agile Estimating (take two)

5. • Prioritised, refined, estimated (to a degree) backlog
– Higher clarity on items and estimates at the top
– More vagueness and questions as we go down
• We answer “When will it be done?” by considering:
– Teams velocity
– Backlog status
– Confidence in the definition & estimate of the backlog items
• What that means is we say “Given what we know at this point, if
nothing changes we forecast that we will be able to complete this
item between X and Y dates/releases”
Agile Estimating – The Outcome

6. • People don’t tend to like the word forecast. At least, they often exchange it with
the word “commitment”
• Even if they do accept the word forecast, customers often don’t
• Even if customers accept the word forecast, that doesn’t stop people being
unhappy as things change – software delivery is usually only a small piece of a
larger project
• Things always change.
• You -always- have more work to do than available capacity
• Backlog items will almost always grow in size as it gets closer to being prioritised or
while it’s being delivered
Agile Estimating – What’s the problem here?

7. The stakeholders say they need to know what will be
delivered, what it will cost, and when they can expect
it.
So:
• Give them a date with plenty of contingency built in
• Do highest-value-thing-first (Agile, right!?) so if you
run out of contingency you might not get fired
Let’s Get Realistic

8. Scope
Cost Time
Quality
The Iron Triangle

9. • Choose a date for release and announce high level
feature list
• Flex scope within high level definitions
e.g. “when we announced support for Word, we meant just the latest version”
• Work on highest value parts of each feature, what
makes the date is released
• If the chosen date is “every two weeks” it looks a bit like
Scrum!
Fixed Date, Flexible Scope

10. • Announce feature list (aka Roadmap)
• Doesn’t matter what order things are worked on, it all
needs to be done
• When it’s all done, release it
• If you can get away with announcing one small feature
per team, it’s might be getting close to being Agile
Flexible Date, Fixed Scope

11. Context: this is an approach being considered (not yet
adopted) in a company where:
• Need to set customer expectation of delivery dates a long
way in advance of really knowing
• Don’t want to give commitments that set teams up to fail
• Don’t want to just “pad the estimates” – work grows to fill
the time allowed!
• Want to empower teams to own the whole problem
Something new...

12. • Create prioritised list of high level features
• Have team(s) provide range estimate for each
– State assumptions being made about scope etc.
– Estimate based on "I'll be surprised if...“
– Estimate in whatever unit you prefer (Number of Stories, Story
Points, Ideal Days, etc.)
• Each sprint the team works to reduce the estimate of
remaining work; methods to do this could include
– Build some of it
– Find a library that does it
– Get scope reduced
• Latest expected dates can be communicated
Range Estimates And Reduce

13. • Team estimates work as 50 – 120 stories (it's a big
initiative)
• In first sprint the team completes 5 stories, and feel a bit
more confident they understand the scope
• Remaining estimate is 45 – 100 stories
Example Scenario 1

14. • Team estimates work as 50 – 120 stories (it's a big
initiative)
• In first sprint the team does some research and finds a
library that meets most of the requirements, and agrees
with stakeholders the other requirements can be
skipped
• Remaining estimate is 10 – 20 stories to integrate the
library
• Great job!
Example Scenario 2

15. • Team estimates work as 50 – 120 stories (it's a big
initiative)
• In first sprint the team does some research but doesn't
find anything that will help
• Remaining estimate is 50 – 120 stories
• Looks like the team did nothing for a sprint
• PROBLEM: if we're not prepared to accept scenario 3,
then we never get scenario 2
Example Scenario 3

16. • Team estimates work as 50 – 120 stories (it's a big
initiative)
• In first sprint the team discovers missing assumptions
which mean the work is larger than they thought
• Remaining estimate is 60 – 140 stories
• This is good – we understand the work better
• PROBLEM if managers just look at the number and not
the reason for the number this looks bad
Example Scenario 4

17. • Team estimates work as 50 – 120 stories (it's a big
initiative)
• In first sprint the team doesn't find missing
requirements or assumptions, but just decides work is
bigger than they thought
• Remaining estimate is 60 – 140 stories
• Team should try getting better at estimating
• PROBLEM if managers give team a hard time over this
they'll learn to pad their estimate next time
Example Scenario 5

18. • Team estimates work as 50 – 120 stories (it's a big
initiative)
• In first sprint the team doesn't change requirements or
assumptions, but just decides work is smaller than they
thought
• Remaining estimate is 30 – 90 stories
• Team should try getting better at estimating
• PROBLEM team might be worried that managers think
they were padding the earlier estimate
Example Scenario 6