In this chapter, we will look at some of the units of measurement that are popular for teams using relative estimation, including:
These units of measurement are often used with user stories.
User stories are short descriptions of a product enhancement (i.e. a product feature) expressed in the following format:
As a < type of user >, I want < some goal > so that < some reason >
An example of a user story would be:
As a marketing manager, I want to apply free delivery to all shoes listed on our website for a specified period so that I can run promotions.
One of the common fallacies with breaking down features into tasks and estimating how long each task will take is that this approach makes a lot of assumptions.
One of the main assumptions is that since the tech team works 40 hours a week , you can assign 40 hours of development tasks to each of them.
However, consider some things that could happen in the typical day of a developer:
She attends meetings.
A fellow developer asks her for help.
She takes a lunch break.
Business people ask her questions and answering them takes 15 minutes.
She takes some toilet breaks.
A weird bug on the live production site needs some researching.
In a previous section, we estimated how long it would take to read a book by first estimating size and then how long it would take to read. Ideal time allows you to do just that.
Ideal time is how long a developer would take to complete a task if they worked on that task without interruption or breaks.
Estimating something using ideal days would require another calculation altogether to determine actual calendar days required to release a feature by a certain date.
One major benefit of ideal time or ideal days is that it is very easy to understand. If you explain to a business stakeholder that developers work for four hours on coding per day and four hours on planning, meetings, lunch, toilet, answering questions and so on, they can better understand the estmates.
If using the Agile project management framework called Scrum, estimation will be done in story points.
Story points are abstract units of feature complexity.
Story points are units that are given to each feature during an estimation session - the available set of numbers are inspired by the Fibonacci sequence.
Story points usually simplify the Fibonacci sequence by going up as far as 21 and then including the number 100 as the biggest number. Although 100 is not a number in the Fibonacci sequence, it is a very big number in this context and is interpreted to mean that the feature is too big to estimate and should be broken down.
When estimating in story points, decide whether a feature's complexity is one of the following:
100 (too big to estimate)
Story points tells you the complexity of the feature (how big it is) but how long it will take to complete.
T-shirt sizing is where you attribute one of the following t-shirt sizes to each feature:
S - Small
L - Large
XL - Extra large
XXL - Extra extra large
One great thing about T-shirt sizing is that it is very easy to understand. Almost anybody can tell you whether they think something is small, medium or large. (In fact, it may remind you of the coffee cup example earlier in the course.)
T-shirt sizing also preserves the main requirement for relative estimation in that you first estimate complexity and then consider how long it will take. Identifying that a feature is a medium, does not tell you how many days it takes to complete. That question would require a separate exercise.
NUT is an abbreviation for Nebulous Units of Time!
It is another label for a unit of relative measurement.
NUT is considered a little flamboyant and places the emphasis on the arbitrary and "made-up" nature of this unit of time. It is clearly an artificial unit and not real time.
When using relative estimation, estimate in units other than calendar time.
Popular units of measurement for relative estimation are:
If using an Agile project management framework called Scurm, estimation will done in story points.
A nice article on using Story Points in Agile development.