The language they understand is months and dollars (or any other type of currency).

The language they understand is months and dollars (or any other type of currency).

Clients, stakeholders and pointy haired bosses really do care about how long a project will take, how much the project will cost and by extension the effort required to deliver the project. What clients, stakeholders and bosses don’t care about is how much the team needs to think or the complexity of the stories or features, except as those attributes effect the duration, cost and effort.  The language they understand is months and dollars (or any other type of currency). Teams however, need to speak in terms of complexity and code (programming languages). Story points are an attempt to create a common understanding.

When a team uses story points, t-shirt or other relative sizing techniques, they hash a myriad of factors together.  When a team decomposes problem they have to assess complexity, capability and capacity in order to determine how long a story, feature or task will take (and therefor cost).  The number of moving parts in this mental algebra makes the outcome variable.  That variability generates debates on how rational it is to estimate at this level that we will not tackle in this essay.  When the team translates their individual perceptions (that include complexity, capacity and capability) into story points or other relative sizing techniques, they are attempting to share an understanding with stakeholders of how long and at what price (with a pinch of variability).  For example, if a team using t-shirt sizing and two week sprints indicate they can deliver 1 large story and 2 two medium or 1 medium and 5 small stories based on past performance, it would be fairly easy to determine when the items on the backlog will be delivered and a fair approximation on the number of sprints (aka effort, which equates to cost).

Clients, stakeholders and bosses are not interested in the t-shirt sizes or the number of story points, but they do care about whether a feature will take a long time to build or cost a lot. The process of sizing helps technical teams translate how hard a story or a project is into words that clients, stakeholders and bosses can understand intimately.

#NoEstimates  . . .Yes or No?

#NoEstimates . . .Yes or No?

 

Hand Drawn Chart Saturday!

When I published An Estimation Framework Is Required In Complex Environments, several people that I respect, including Luis Gonçalves (interviewed on the SPaMCAST 282 with Ben Linders), begged to differ with my conclusion that a framework was ever required.  Luis made an impassioned plea for #NoEstimates.  The premise of #NoEstimates is that estimates enforce a plan and plans many times are overcome by changes that range across both technology and business needs.

Vasco Duarte, a leading proponent of #NoEstimate describes the process as follows:

  1. Select the highest value piece of work the team needs to do.
  2. Break that piece of work down into small components.  Vasco uses the term risk-neutral chunks, which means pieces of work that if they don’t get delivered in the first attempt will not put the project at risk.
  3. Develop each piece of work according to the definition of done. #NoEstimates makes a strong case that unless done means anything other than usable by the end customers, the project is not getting the feedback needed to avoid negative surprises.
  4. Iterate and refactor. Continue until the product or enhancement meets the organization’s definition of done.

Estimates are part of a continuum that begins with budgeting, continues to estimating and terminates at planning.   Organizations build strategic plans based on bringing new or enhanced products to market.  For example, a retailer might commit to opening x number of stores in the next year.  If public, once publicly stated, the organization will need to perform to those commitments or face a wide range of consequences.  Based on experience gathered by working in several retailer’s IT organizations, I know that even a single store is a major effort that includes store operations, purchasing, legal and IT.  Missing an opening date causes embarrassment and typically, large financial penalties (paying workers who aren’t working, rescheduling advertising and possible tax penalties not to mention the impact to stock prices).  Organizations need to budget and estimate at a strategic level.

Where the #NoEstimates approach makes sense is at the planning level.  The #NoEstimates process empowers teams (product owner, Scrum Master/coach and development personnel) to work on the highest value work first and to develop a predictable capacity to deliver work.  The results generated by the team provide feedback to evaluate the promises made though organization-level budgets and estimates.

When performance is at odds with what has been promised business choices should be made.  Choices can range from involving other teams (when this makes sense) to accepting the implications of not meeting the commitments made by the organization.

Does #NoEstimates make sense?  Yes, the process and concepts embodied by #NoEstimates fits solidly into a framework of budgeting, estimating and planning.   Without a framework to codify the use of #NoEstimates and to govern organizational behavior, getting to the point of making hard business choices will generate pressure to fall back to command and control fashion.

Note:  I am working on scheduling an interview and discussion with Luis and Vasco on the Software Process and Measurement Cast to discuss #NoEstimates.