This document discusses the NoEstimates approach to software development. It begins by defining estimates and explaining that NoEstimates is about minimizing estimates rather than eliminating them entirely. The main goals of NoEstimates are to evaluate progress in a concrete way and force teams to slice work into smaller stories. Key benefits include being faster, easier iteration planning, and minimal time spent estimating. Progress is measured by the number of "Running Tested Stories" completed. The document also covers challenges, case studies, and debates around using NoEstimates versus more traditional estimating approaches.

1. NoEstimates
Compiled and Presented by Kamal Tejnani
Agile Student 
Kamal.Tejnani@gmail.com
988 45 80802

2. Ground Rules
• Lightning Talk for 10-15 mins
• QnA at the end – please park your questions

3. Outline
• What are Estimates
• What is NoEstimates
• Case Study on NoEstimates
• Take on NoEstimates

4. What are Estimates ?
‘to give or form a general idea about the value, size or cost of something’
- The Merriam-Webster Dictionary
From this, we can deduce that estimates are ideas.
Sometimes those ideas are vague, and other times they are very precise or
accurate, but they are ideas nonetheless.
Hence, estimates are guesses, not facts.

5. Disclaimer
• Not yet a proponent of NoEstimates
• Just presenting another perspective on Estimates and Delivery

6. #NoEstimate - references
The BookTwitter Handle – Woody Zuill

7. What is NoEstimate
• NoEstimates is not about no estimation ever, but about the minimum
amount of estimates that will do, and then look carefully at ways to
reduce that need even more.
• In essence this means not trying to estimate the size of the work; we
just make sure we slice work into a size that we can bite on and turn
around quickly.

8. Main Goal of the NoEstimates Movement
• To help evaluate progress in a concrete – and easy to implement –
way.

9. Benefits of NoEstimates
• It is faster.
• It also forces teams to slice into smaller stories.
• Iteration Planning becomes even easier, because you just need to
understand your velocity and how many stories you can fit.
• You spend minimal time estimating.

10. How to measure Progress
• “Working software is the primary measure of progress”
RTS Stories (Running-Tested-Stories ) is the equivalent of this and is the only
metric used in NoEstimates
• 1. Requirements need to be written in a way that allows you to measure
progress early and often during the project.
• 2. Requirements need to be written in a way that provides you with the
necessary flexibility to make decisions on what part of each requirement
will be implemented later, when you better understand the system, and the
business needs.

11. NoEstimate – Progress revisited
• deliver several stories per week
• assess the time it takes to deliver multiple Stories, which would in
turn help forecast future progress.
Slice your Features and user stories so that you can review progress on
a daily or at least weekly basis. In practice this means that every week
several stories should be completed to allow you to assess progress.
And every few weeks (every month or so) several Features should be
completed.

12. How to measure Progress
Running Tested Stories (RTS)

13. When will the Project be delivered – Progress
Revisited • How many User Stories can a team deliver on an
average week? (The User Story velocity).
• How many Features can our project deliver on an
average week? (The Feature velocity)
• Is the feature comprising of the user stories the smallest,
largest or medium feature – Extrapolate remaining work
based on this.

14. NoEstimates Principles
• No Huge Stories
Each Story is small and all Stories are pretty homogenous in size which means that
you can focus on their Value instead of their cost in making a decision
• Independent Stories in a Sprint.
Each Story can be dropped from the project without affecting the overall project
delivery
• Target 1 RTS per team member per day – look out for 0 RTS for one or more
team members for more than 1 or 2 days
• Approximately same number of small-medium-big stories in each Sprint

15. NoEstimates – INVEST principle redefined
• NEGOTIABLE
o Define a very clear capability for the system, but do not dictate an implementation strategy, or
very specific functional requirements.
o This property allows the development team to select an implementation strategy that best suits
the project when the time comes to implement that Story, and
o allows the customer to be engaged in defining the detailed functionality later on based on the
running demo of the software.
• ESSENTIAL (instead of Estimable):
o A story must not only be valuable, but it’s removal must make the product
unusable or unsellable.
• SMALL
o Stories should be between 0,5 and 1 man-days of effort. Establish that as your target, and
slowly move towards that size. Your visibility to progress and quality will slowly increase as the
size of the Stories decreases.

16. NoEstimates - Workbook
• What is the most important value to be delivered by the project from the customer’s perspective?
(Purpose of Each Release)
• When does the project need to go live with the first release?
• What does the customer expect to accomplish with that first release?
• How many, and which, Running Tested Stories (RTS) do you need to deliver until that first release?
• How many RTSs have you successfully delivered during the last 2 months (the length of the project until then)?
For example, if you have 10 weeks to the next delivery and you have 20 Stories that should go into that delivery, you know you
need to deliver an average of 2 Stories per week to make that delivery. If you deliver less, you should then evaluate the scope
and make the necessary reduction. If you deliver more, you are on target and may be able to deliver more functionality at the
end of the 10 weeks.
The first question about the purpose of each release is the most important. By understanding the goal of your customer you will
be able to “steer” the delivery by evaluating, prioritizing and ultimately removing Stories from that delivery. Without an answer
to the first question, the most important tool for the #NoEstimates practitioner (scope management) will not be available.

17. NoEstimates - Workbook

18. Blink Estimation
“does this Story feel like it could fit into a 2-week sprint?” If the answer
was yes, we took it in, if not, then we broken it down further.
Not much time was wasted in those conversations; the goal was to
get started doing the work to assess if we were indeed able to deliver
that Story in 2 weeks.
…having a consistent rate of progress is more important than
estimating a project. This consistent rate of progress will help steer
the project in a very concrete way

19. NoEstimates – Multiple Levels of Granularity
• Features – that cannot be delivered in a n-week Sprint
• User Stories – that can be delivered in 0.5-2 day(s) within a Sprint
Approx. 2 stories
being delivered
per day

20. Rolling Wave Forecast
• At the heart of the rolling wave forecast is
the acceptance of uncertainty
• Create Scenarios of the Future
• Speculate how events will unfold and
evaluate possible outcomes for the different
events
• This forecasting mechanism allows the
project team to know when they are likely to
deliver a certain Feature and therefore also
coordinate work with external project
contributors.

21. NoEstimates – based on lessons learnt …
• only when we start working on a Story that we actually know how
long it will take to deliver
• breaking down Stories helps us assess progress at the project level
faster, and make the necessary (and inevitable) scope decisions. Not
all stories are critical
• Finally, having a consistent rate of progress is more important than
estimating a project. This consistent rate of progress will help us steer
the project in a very concrete way: reduce work or re-prioritize work
based on actual progress data, instead of a guess at a plan that will
invariably change

22. Challenges to doing NoEstimates
• Thin Vertical Slicing of User Stories as RTS of 1-day duration
• Creating Independent Stories of homogenous size (if 1 day ? )
• Historical data especially if features to be delivered are different,
technology is different, team might be different etc.
• Customer will accept reduced scope delivery

23. Case Study #1 using NoEstimates
http://www.qondor.com/
A travel and event management tool used by industry leading
companies across 9 countries, including Egencia / Expedia, the largest
travel management company in the world.
The system is mission critical to the users - if the system stops working,
they will not be able to do their job.

24. Case Study #2 using NoEstimates
• Don Wells, an early Extreme Programmer who worked on the Chrysler
Comprehensive Compensation System project (the birthplace of XP)
Each week we just choose the most important items and sign up for them up to the number from last week. It turns out that
we get about the same number of them done regardless of estimated effort. We have 1 week iterations so we tend to break
things down a bit at the iteration planning meeting.
…. the point is we get about 8 things done each week, no estimation required.

25. Does NoEstimates answer these …
To know when we can release software to our users (Missing the
season ?)
What it will roughly cost to develop and deliver the software
(Budgetary Constraints)
For Proposals (Can you say I will not give a quote ?  )
Boss/Client wants it …

26. Arguments against NoEstimates
• What if Customers WANT estimates
“Customer Collaboration over Contract Negotiation” – if customers want estimates, we
have to give them estimates
A US based large Financial institution outsourcing development and testing work to
India using a T & M mode
They will “want” estimates 
• If a lot of the estimates are inaccurate - So should we not improve estimation
• The time spent creating estimates is wasted
But if you get better at estimating, you’ll spend less time producing better answers and
the time won’t be wasted

27. #NoEstimates versus #Estimates debate
• In which projects #NoEstimates work
• Can #NoEstimates work in big projects
• Need more case studies for #NoEstimates

28. Estimates – a simple case study
• Suppose a family wants a kitchen to be built comprising of drawers,
exhaust, floor cabinets, wall cabinets, water filter compartment, gas
cylinder cabinet, steel sink
• Budget is Rs. 2 lakhs.
Can we tell the family to prioritize everything and then we will continue
doing things in the order of priority and it will take as much money as it
takes.
At least some indication needs to be given

29. Kamal’s take on NoEstimates
• RTS
I have been doing this for a long time
Estimations
I do Relative Sizing at the Release Level and Task driven Capacity at the
Sprint level. The teams are empowered to not allow anyone to arm
twist them to take up more work than what they think they can commit

30. NoEstimates – Further Learnings
• The Ultimate Guide to Capacity Planning with NoEstimates by Tomas Rybing
• The #NoEstimates Pioneers on Video:
o Woody Zuill, the creator of the #NoEstimates hash tag on twitter
o Neil Killick, the creator of the Slicing Heuristic, a great way to reach #NoEstimates quickly
• Henri Karhatsu, greatly experienced #NoEstimates practitioner with many stories to share
• 4 video interviews with #NoEstimates practitioners
o Chris Chapman
o Marcus Hammarberg
o Allan Kelly
o Clinton Keith
• 2 video interviews with CEO’s that apply #NoEstimates in their own organizations
o Sven Ditz, CEO of Sitegeist.de in Germany
o Diego Cenzano, CEO of biko2 in Spain
.

31. THANK YOU
Q n A