This is my fifth blog post on the subject of #NoEstimates. You can find the previous ones here:

Some of them have ”stirred up some dust” in the agile community. In fact, other people have wrote their own blog posts based on them.



To continue the analogy of indicators found in a normal car, the time has now come to the GPS (Global Positioning System). What is the primary function of a GPS? It’s of course that it can tell you exactly where you are. Wouldn’t that be great to have in software development? My experience is that the ”accuracy” of our current location can be uncertain at times. For example if we are working to fix a critical bug. We don’t know if we can fix it in one hour or one day. To be fair, not even the GPS has exact precision (accuracy is in theory 15 meters for civil GPS:es).

The second big thing with a GPS is that you can give it a destination and it will plan a route to get there from where you are. You can even choose if you want to go the shortest of fastest way! Recently we went on a trip by car to the northern parts of Sweden to go skiing for a weekend. We drove along and the GPS told us things like:

  • How far we have gone (from our starting point)
  • At what speed we where going
  • How far it was to the destination
  • The estimated time of arrival at the destination

On the car trip a thing I haven’t really thought about popped into my mind. After a while we turned into a new road that was not in the GPS, and it got confused. It started to say that we should turn back, but after a short while it ”accepted the fact” and said ”Re-planning the route”. Then it struck me, this would be a great function to have in software development! To a) know where you are and b) have the possibility at a low effort re-plan the route, if and when, we hit upon an obstacle in our journey. To me this is what agile is all about, to have the possibility to adapt and constantly re-plan considering reality (i.e, that things change) and not headless trying to stick to an initial plan (like in Waterfall).


The GPS for software development needs to be able to answer these four questions:

  • Where are you?
  • At what capacity are you operating right now (speedometer)?
  • What is your destination?
  • How to get there?

I you have all that, it’s pretty simple to re-plan the route, don’t you think?

There is one more thing that you have to consider for your SW-GPS and that is what accuracy it should have. There is a decision to make here:

  • High accuracy – If you want to have high accuracy, the effort (and thereby cost) to re-plan would be high. Maybe your context requires this, you have to commit to firm deadlines that involves penalties if not met (this is not very agile and more like the old Waterfall by the way). To be able to be more precise, a GPS needs to have contact with several satellites. In the case of a SW-GPS it would mean a lot of metrics and check-points and a fair amount of work to be able to produce a re-plan of the route.
  • Medium accuracy – You want to be able to predict, and you have the data that you need easily at hand. Giving promises regarding time, you are allowed to use a span.
  • Low accuracy – Maybe you already have high organizational trust and predicability in your deliveries? Maybe you don’t need to make commitments in time at all? Congratulations, you are truly agile! Your need for a SW-GPS is little, use it to set out the direction where you want to go, and check with regular intervals that you are on track. You don’t want to make a U-turn do you? 🙂

For most of us I think, we can use medium accuracy.


To get you inspired, I give you a fictive example on how the SW-GPS could work. Assume that we have a project with 100 tasks. 30 of them are 100% completed, meaning implemented and tested and delivered to a production like environment. They don’t add any technical dept (and if they do, the dept is known, and there is a plan to fix it later after this project). The current capacity is 10 tasks/week.

Let’s check the SW-GPS:

  • Where are we? 30 of 100
  • At what capacity are we operating? 10 tasks/week
  • What is our destination? 100 of 100
  • How do we get there? Complete 70 more
  • When do we get there? Approximately 6 – 8 weeks

On our journey we now hit an obstacle. Original plan was to ”go right” towards the destination, but that is not possible. We have to ”go left” on a longer road. We anticipate the road to be 10 tasks longer. What could this be in real life? Maybe we hit a performance problem and have to re-write old code.

Let’s check the SW-GPS again:

  • Where are we? 30 of 110
  • At what capacity are we operating? 10 tasks/week
  • What is our destination? 110 of 110
  • How do we get there? Complete 80 more
  • When do we get there? Approximately 7 – 9 weeks

Work continues and we manage to fix the problem, only 5 ”extra tasks” had to be added, we are now ”back on the main road” again. Check the SW-GPS again and repeat all over.


Wouldn’t it be neat to have a SW-GPS with the ability to constantly re-plan your route towards the destination? The re-plan process must be quick and light-weighted with a short turnaround time. Hence based on data that can be easily tracked and used for simple calculations. What do you say? I will try to implement this now.

Blog post update:

@duarte_vasco pointed me to the speech below by @gojkoadzic. This is so spot on it hurts! Gojko talks about using the GPS for navigating software development 100 times better than I ever could. This is a must watch 🙂

All the best,
Tomas from TheAgileist

One comment

  1. Nice post.

    This is a good analogy and even better if you were to add the statistical process control used by Google mapping software (or Garmin). The route time is calculated by looking at the external conditions along the selected path. On a cell phone there is realtime data from all others along that same path. This is what allows Google Maps to change the color of the roadway (at least in the US) from the other travelers on that path and show you delays and “actual” progress versus projected progress.

    As well each of those progress measurements is statistically adjusted using “past performance” with a trailing history to complete not only the Average and Variance but also the dynamics of that Average.

    The simple averaging in the link above from the proponents of #NoEstimats dos not pass the “smell” of being statistically sound. Six Sigma, any quality control, any process control mechanism cannot function on averages alone. To make decisions using averages will result in disappointment of arriving “not as planned”

    And that “arriving as planned” is the basis of all business success. Too early or too late may or may not be the needed condition. But “as planned” – assuming there is a strategy stating what is needed, is the”closed loop control,” processes needed for success


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s