Agile Estimation: Guessing Intelligently

Estimation is fundamentally a “guessing game” but in many environments, it is seen and used to make predictions or commitments as to when something will get done.  Even worse, is that many organizations focus very hard on trying to make commitments in the large instead of in the small.  It’s been stated many times that product development is the art of creating new recipes.  There is so much uncertainty in the large.

I actually believe that estimation is an activity that should be done as infrequently as is possible and when done, should be extremely light-weight.  I know this might be a bit controversial, especially for my traditionalists friends, but hear me out.  I don’t see estimation as a much of value-add to the product development process in most cases.  Estimates in the large ultimately create undue pressure (not challenges) and try to impose order on an inherently complex systems.  Unfortunately, we don’t learn and keep trying and keep failing. Einstein had a description for such behavior.

This post is going to look at estimation in the case where a “Fixed Date” is not in place but we need to get a sense of the effort required in order to determine what should be done next or as input into a high-level release plan.  A “Fixed Date” means that a solution much be delivered or live by a certain date.  In the absence of this constraint,  I suggest a completely different approach to estimating. There is a lot of effort (possibly overhead) in planning for a Fixed Date so it must be worth it.

The smaller the work item, the better we generally are at estimating.  The smallest work item is usually a “task” and so if you are looking for an accurate estimate that will translates to effort (cost) and schedule (delivery), then a user story/requirement/whatever should be decomposed into all its composite tasks and every single task should be taken into consideration. I have made the mistake in the past of not having every different role explicitly specify and estimate their tasks.  For example, instead of having a business analyst, developer and tester estimate the same line item, each role estimate their tasks separately.

However, when beginning a new initiative (such as adding a new module) referred to as “themes” in agile speak and “requirements” in other contexts, the tasks are pretty obscure, so what do you do when you’re required to give an estimate?  Well you could go through the process of decomposing down to tasks but as mentioned above, except there is a “Fixed Date” for delivery, I wouldn’t do that.  I would start with T-Shirt sizes.

T-Shirt sizing provides an avenue to quickly categorize and classify themes into buckets without expending too much effort.  Now these sizes need to tie back to a common unit of measure.  In my experience, non-product development folks may not understand things like “story points” (if you are using user stories) and so hours/days may need to be used i.e. develop estimates in the language currently spoken in your environment.  I believe in using ranges in estimates given the uncertainty that is product development and to account for the cone of uncertainty.  So an example (in hours) that I just used recently could be:

  • XS:    1 – 100 hours
  • S:       100 – 500 hours
  • M:     500 – 1000 hours
  • L:       1000 – 2000 hours
  • XL:    2000 – 5000 hours
  • XXL: 5000 – ?

The key is to use a scale that works in your environment.  Maybe all your requirements are smaller i.e. under 1000 hours, then XL would be 1000 – ?.  The disadvantage with using hours/days is that most product developers are tempted to want to breakdown themes into tasks in order to provide what they consider “better” estimates.  A way to mitigate this, is to find a baseline item to work with, such as previously completed initiative (historical data) or another item within the list of themes for which there is more “confidence” about its estimate. Another key point to emphasize is that we’re just attempting to identify at a high-level how much work we think we have.  By no means should concrete plans be made on such estimates.

A question that I often get asked, is ‘who’ do I think should provide these “high-level” estimates, especially on teams with different roles involved.  This is a little tricky because different roles bring different perspectives to the table.  However, my general answer is that the senior technical people who understand the domain should be the primary estimators at this level and it should ideally be more than 2 people.  Leverage the wisdom of the crowd.  Use the Wideband Delphi method.  When discrete tasks are being estimated, get everyone involved.

Assuming the “cost of delay” for a theme has been determined, the result of the estimation process should help drive the selection of the factor should determine.

What do you think?  How do you (if you) estimate large requirements or themes?


Effectiveness or Efficiency?

On one of the discussion groups that I’m a member of had a thread that started a discussion on what software development is really after, effectiveness or efficiency.  I’ve thought about this over the past couple of days and just decided to dump some thoughts on the matter.

Borrowing Peter Drucker’s definitions for the two words, effectiveness means “doing the right things” and efficiency means “doing things right”.  Note that both things are inherently mutually exclusive.  If I am driving to work in the wrong direction, I’m being efficient (by driving since by walking I would never get there) but not effective because I’ll never get to work. However, if I take the scenic route to work adding another hour to my commute, then I’m being effective (I will arrive at work) but probably not that efficient. Generally speaking, one always wants to be effective, but being efficient could be considered optional.  So if this is the case, which is more important in software development?

I grew up in Nigeria and spent a good portion of my childhood cutting grass and thick foliage with either a cutlass or machete. 
It was a highly effective way of cutting the grass as it got the job done. It also left me very hungry afterwards!   But I remember having to spend days cutting grass given the size of portions I had.  Interestingly enough, on the university campus that I grew up on, the landscaping team also used cutlasses to the cut the grass of all the fields on campus.  It would take days for them to complete, and areas like our football (soccer for my American friends) fields would be last on the list causing us to go weeks without playing at times.  For those who know me well, you definitely realize how tragic this must have been for me.

Then the university made an investment in riding movers and all of a sudden, it no longer took weeks to cut the grass, it was all done in a matter days.  The university leadership realized that even though the right thing was being done (effectiveness), it wasn’t being done in the right way (efficient) given the size of the campus. Introducing riding mowers allowed the grass to be cut quickly and consistently, improving the overall aesthetics and beauty of the campus.  It also opened up the doors for the landscaping team to do other things besides just cut grass! Most importantly, it allowed yours truly to play football whenever I wanted to because the fields were always in tip-top shape. The landscaping team was now both effective and efficient.

It’s easy to understand why being effective is important – we all want to do the right thing and I would suggest that a lot of our energies go towards effectiveness (especially when agile practices are employed).  It’s much easier to see ineffectiveness.  Your “customer” will tell you. Efficiency on the other hand can be a little more subtle – it’s harder to see, harder to challenge and harder to understand.  If things are working (effective), in my experience, efficiency takes a back seat.  The classic “if it ain’t broke why fix it ?” approach to things. Yet, efficiency allows us to scale our operations providing us with the opportunity to do other things including living more fulfilling lives!  We are inherently making our company more profitable because we are possibly getting more done in the same amount of time as before. Remember, time is money.  For example, manually  executing a hundreds of test cases may be very effective but is probably inefficient and so to improve efficiency, we decide to automate tests allowing testes to focus on exploratory scenarios or help with requirements gathering.  We don’t need cross-functional teams to be effective.  We introduce cross-functional teams because makes all the roles/functions needed to deliver solutions readily available to us.  It reduces communications challenges and allows us to respond to each other in minutes instead of days.  It improves the overall efficiency of the team.  The same is true for co-located teams.  That being said, it’s important to note that improving efficiency can also be an expensive undertaking. It’s important to a have “sense” or “feel” for what the gain in efficiency is really going to provide and what the objectives are.

Is it okay to be inefficient in order to be effective?  Sure.  I’m familiar with at least two cases (I imagine there are others) such as having multiple people on a team researching a critical production issue or not having members on the team with siloed responsibilities such as “application developer”, “database developer” or “UI developer”.    We’ve given up some efficiency in order to be effective by allowing everyone to do some UI development for example.  

We should understand that in figuring out the “unknown” as we often do in software development, we will not be as efficient as we could be if we knew exactly what we were doing.  (Think about all the hallway discussions that occur or the back and forth that we end up realizing was not necessary after the fact).  We are conducting a bunch of experiments, coming up with new recipes.  That being said, it’s not an excuse to accept inefficiency as the status quo.  Practices such as TDD, using user stories to gather requirements and just-in-time planning, using dynamic languages to name a few, provide efficient approaches to working with uncertainty and vagueness.

Let me suggest that both effectiveness and efficiency are equally important in software development (except when what is being developed and delivered is of little consequence – why are you working there?) and software teams should focus on continuous improvement in both areas.

Photo of my very own cutlass

Riding Mower photo from Jeff Harbert

The truth and nothing but the truth

The blog posting  ORA-00001: Unique constraint violated popped up on Hacker News over the last couple of days (if you don’t follow Hacker News, you should) and fortunately for me I read it today.

Why this article is important is that it directly addresses myths that surround database development (or developing with stored procedures) that are so commonly held.  Let me be clear, I cut my teeth developing with programming languages that run outside of the database such as Pascal, Fortran, C, C++, Java, C#, Ruby and Python so I have no reason to promote PL/SQL or T-SQL but in this age of mis-information, it’s important that the truth be told.

Developers should have at their disposal all the tools needed to effectively build applications regardless of the languages being used. However, I’ve been around teams where there are two types of developers: application developers and database developers that are depended on to deliver solutions.  Curiously however, software development is partitioned in such a way that no one type of developer can actually deliver a solution from top to bottom.  For example, application developers don’t implement logic or database developers don’t develop user interfaces (or Windows services or file outputs).   So in the effort to get the best of both worlds, the team becomes highly inefficient and partially hamstrung.

Figure out what tools you want you to use and just get good at them.  Understand the contexts where they work best and leverage them.  Use the proper software development practices across the board.  Have software developers armed with the tools to deliver solutions in their entirety.  If some part of software development is a black box to you, go figure out, ask questions.  Just don’t drink the Kool-Aid.