Estimating with limited information

Best client ever. You have gone through all the steps on the elicitation stage. You have worked on the epics broken them down properly and now have a healthy backlog of user stories that is representative of the app you will be building and now you can work on estimates. Awesome right?

Yes that would actually be awesome except in reality it just never happens. More often than not the client will want at least a ball park figure from the initial meeting when all you have is just a story.

The ideal way would be to reject this option and insist on a proper elicitation phase. Unfortunately that may not be practical. Fortunately there is a way of still getting to an estimate albeit a rough one.

Introducing function points.

Almost all business applications can be decomposed to the following major categories.

Inputs

Includes the ways available to the user to feed data to the application. For web applications this would be forms, for mobile applications this would be dialog boxes, controls etc.

Depending on the application, exotic options maybe available such as finger tracking. They would still fall under this category

Outputs

What the system displays back to the user.

Most common options would be:

  • Tables
  • Graphs
  • Messages
  • Reports

The only requirement is that the output be targeted at a human consumer.

Inquiries

Very similar to outputs with the distinctions that inquiries return results in raw format. This can be consumed by humans or machines.

The distinction is important because you rarely have to write a lot of code to get inquiries going.

Most common examples would include:

  • Database queries
  • Simple search
  • API GET to a simple resource

Logical Computations

Would include major manipulation to the data that is to be done by the system. Unless your system is purely CRUD, you will need this layer as the value add for your application.

Most common examples would include:

  • Run payroll for all employees
  • Calculate shortest distance between two points
  • Convert file types

Integrations

In the connected world your app probably works with multiple other services to bring value to the user. You need to take this into account when doing your estimates. Examples of such would be:

  • Social login
  • Connection real time technlogies. eg Pusher, Firebase
  • Remote DBs eg Big Query
  • Remote file systems eg Dropbox, S3

Multipliers

Not all items in the categories would be equal in weight. As such you need to apply certain multipliers to the items to equalize them. Based on empirical analysis of software projects by Casper Jones in the book Applied Software Measurement: Global Analysis of Productivity and Quality. We have a reasonable basis for such weights.

Note in our nomenclature we classify Logical Internal Files as Logical Computations and Logical Interface Files as Integrations.

Example

Suppose now you have come from the client meeting and you managed to pick up they would need an authentication system with Google+ and Twitter login. How would you go about that?

Starting with the categories highlighted above as a ticker list you would come up with something like this.

Epics are the major areas you we’re able to pick out. The categories are as discussed above. The complexity is a subjective opinion of the item to be built. For example in my case I consider complexity of login form in category Inputs to be low but consider a registration page in category Inputs to be high.

From this data we can now calculate the number of points based on Casper Jones multipliers.

What do the points mean?

The points have given you a size estimate but not a effort estimate. To get a effort estimate in developer hours you need to look back at previous projects to see how points map to time taken for individual teams or developers.

Let us assume that looking at previous data you note that the relation between developer hours and points for your team looks like this

    developer hours = points * 0.5

That is it takes a developer half an hour to complete a point.

Then

    developer hours = 46 * 0.5 = 23

You can thus estimate that your developers will take 23 hours to complete the user authentication.

This estimation technique requires you to keep metrics on past projects but also enables you to very quickly compute estimates once you have a solid record of past performance.

The sheet used to do the computations can be found here. https://docs.google.com/spreadsheets/d/1QEbdeK7TJ39a1efQOEuBu1J-_nP5KMUYTlYPNe7Hf2Y/edit?usp=sharing

Have you ever used point estimation on your own projects tell us in the comment section below.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Software Estimation Workshop

On April 28th from 1:30 to 3:30pm at Strathmore Business School, Moringa DevShop  will be holding a workshop on scoping and estimation.

Software estimation is one of the hardest activities you can engage in. It is not uncommon to meet clients who want exact dates for the exact time and cost it will take to build their software on the first meeting.

The difficulty in this is that neither you nor the client are actually clear on what needs to be done and thus whatever estimate you give is necessarily fuzzy.

In this workshop you will learn how to come up with realistic estimates that you and your team can commit to.

You will learn all about

Process

    • User stories
    • Size estimates
    • Story points
    • T shirt sizes
    • Fibonacci sequence
    • Targets estimates commitments
    • Velocity

Tools

    • Planning poker
    • Spreadsheet templates

Common Gotchas

    • Story points as time units
    • Poor choice of units
    • Tyranny of precision over accuracy

Register now by simply fill in your details at http://goo.gl/forms/3UVfLJQTSl

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Common barriers to information hiding

A core tenet of software engineering is information hiding. OOP rose in popularity owing to how well it was able to implement the concept.

When you have information hiding working for you, an entire class of problems simply disappear. I have previously talked about the concept of complexity in software The heart of software engineering and how to manage dependencies Isolating change in software projects. Today we will be looking at some of the barriers that you will likely face in this endeavour.

Hard code

Yes code can in fact become hard. Or more precisely rigid. This happens when you have design that necessitates multiple edits to the codebase for simple changes.

An example I like to use is the case of the tax rate. Since it’s a figure that very rarely changes you will be tempted to simply use the value throughout with statements such as:

employee_net = employee_gross - employee_gross * 0.3

That statement does not seem dangerous at all, I mean at worst you could do a quick search and replace if need be. And that maybe true but what if you had reference to another 0.3?

expected_annual_return = last_year_value * 10.3

Issues like that line the path to programmer hell.

Circular dependencies

This is a nefarious one. It’s power comes from the fact that at the surface it looks like great engineering.

Lets say you have a code such as:

<?php 

class User(){
  
  function getUserData($username){
    //fetch db data logic
  }
  function changeSubscription($username){
    $login = new Login();
    if($login->checkLoggedIn()){
      //Upgrade subscription level
    }
  }
  
}
class Login(){
  function loginUser($username,$password){
    $user = new User();
    $data = $user->getUserData($username);
    if($data['password'] == Hash::value($password)){
      //user login logic
    }
  }
  function checkLoggedIn($username){
   
    //logic to check if user is online
  }
}

Hidden in the code is a circular dependency. Now you have no way of testing the User class without having first written the Login class and vice versa.

Global data

So now you have moved your constants out and now save them as global information. But you have done more than just move the constants, you have also moved items you figure get used a lot by different classes out to the global space.

The challenge that this gives you is that you now have to consider what other methods that use the same global variable are doing to it as you are writing this method. You maybe the same developer that wrote both methods, but by forcing yourself to hold this information in your head, you have inadvertently created a fertile ground for bugs.

Instead consider making use of class level variables. While the dependency is still  there, now it is made explicit. You can see at a glance how exactly all the other routines interact with the data.

How do you hide information in your own projects? Reach out to me on twitter at @jchex or in the comment section below.

Facebooktwittergoogle_plusredditpinterestlinkedinmail