Introduction
Software estimation is a difficult task. For software developers it is one of the times that they feel put on the spot asked to deliver something with potentially very important implications for the business while not necessarily having all the required info at hand. Even for the most well organized software teams estimation is hard because of the nature of software.
Software is considered to be a rather intangible product, which is realized in the form of texts of various sorts: design documents, program code, user and operator manuals, forms and ultimately only in the observable actions of a computer system. Such systems may be highly complex, multi-functional and linked to a wide variety of other systems involving software, computer hardware and networks. Intangibility and the notorious complexity of software make it difficult to estimate.
Assumptions
It is assumed that the Development team receive a proper “requirements document” or functional specification before detailed estimation begins. The process followed by Business Analysts to produce these documents is not covered by this document.
Some Key Principles
In Agile environments the Product Owner and the team should work closely together at all phases of a project from requirements gathering to development. An estimation meeting will be much better if it involves the Product Owner, the developers assigned to work on the project, the testers and anyone else who may participate in the project. Agile teams are by definition cross functional and everyone in the team should be able to contribute at the estimation meeting. The team will have the chance to understand better the point of view and the business needs of the Product Owner while the Product Owner will be able to appreciate the amount of work involved to deliver the project and the hidden complexities/issues that may arise.
The team is responsible for breaking the project into manageable chunks called user stories that are the individual items that developers can work on.
What is a User Story?
A user story briefly explains:
- the person using the service (actor)
- what the user needs the service for (narrative)
- why the user needs it (goal)
User stories are an essential part of the agile toolkit. They’re a way of organizing your work into manageable chunks that create tangible value, and can be discussed and prioritised independently.
Once a project is broken down into a prioritized backlog of user stories the Team can begin the estimation process.
What are Story Points?
In simple terms a number of Story Points assigned to a User Story is a number that tells the team how hard the story is. Hard could be related to complexity, unknowns and effort.
In most cases a story point range is 1,2,4,8,16 or X Small, Small, Medium, Large, Extra Large. Mostly commonly used series is the Fibonacci series. A Fibonacci sequence is 1,2,3,5,8,13,21,34,54….
Why Story Points?
Software houses are traditionally using some sort of date format for estimating, for example number of days or hours. Most Agile teams these days however started using story points.
Story points rate the relative effort of work in a Fibonacci-like format: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100. It may sound counter-intuitive, but that abstraction is actually helpful because it pushes the team to make tougher decisions around the difficulty of work. Here are few reasons to use story points:
- By far the most important reason for using story points is that it gives the developers the opportunity to calmly assess the difficulty of an issue and give an accurate estimate without feeling pressurised to provide a number of hours or days that may sound “reasonable” to the business analysts or managers to whom the estimate needs to be communicated. We all have the tendency as human beings to be over optimistic when we estimate (or sometimes over pessimistic depending on personality!) and feel the need to provide an estimate that proves that we are fast and efficient. That natural tendency always leads to underestimating the amount of work involved and the time it requires.
- As already explained story points are a better medium of communication between development teams and upper management. Once everyone understands how they work they remove a lot of the emotional and heated arguments around deadlines and delivery dates.
- Estimating in days very frequently fails to take into account the everyday distractions that a Development team has to go through. Story points and a carefully calculated velocity based on historical data takes all that into account.
- Different teams have different skill levels and experience and naturally they have different velocities. Story points and velocity allow you to calculate based on the performance of a specific team for a specific project.
A team that uses story points needs to plan a “poker session”. During the session developers and business analysts go through the list of tasks and once everyone understands what the task is about all developers are asked to provide an estimate in story points. The highest and lowest estimate is discussed and the team usually settles for an average value with which everyone agrees. This process ensures that a relatively accurate estimate is given for all tasks that combines the knowledge and experience of everyone present in the session.
Maximum number of story points
Experience has shown that big items of work that are more than 8-13 story points are hard to estimate accurately. Furthermore, user stories or tasks that are that long usually indicate the need to break the task into smaller tasks and estimate again which is going to be more accurate. For that reason, the maximum of story points that can be assigned to a User Story should be 8. If it is more than this, then the User Story needs to be broken down into smaller stories.
How to turn story points into money
To estimate how many hours it will take the team to deliver a certain number of story points we need to know the team velocity by using historical data. Different teams may have different velocities depending on Project complexity, developer skills and other factors. That is why it is important to measure velocity frequently to get the most accurate estimates for the current team working on the current project.
Velocity is the average number of Story Points the team can deliver in a Sprint (2 weeks usually). The formula below can be used to turn story points into money.
((totalStoryPoints / velocity) * teamDaysPerSprint) * dailyDevelopmentRate
So let’s say we estimated a project to be 100 story points and we know that the team can deliver around 25 points per sprint then we have 4 sprints multiplied by the number of man days the team spends on the project. For 2 week sprints with 2 developers the days are 2*10 = 20 days.
So now we have 4 sprints * 20 days = 80 days of effort which can be multiplied by the dailyRate (let’s say 1000k) which gives us a total of 80,000£.
Contingency
Typically a 20% rule can be applied to give the team an idea of what is the best or worst case scenario for a project after the estimation is complete. -20% is the best case and +20% is the worst case. It is up to the business to decide if it is wise to use the +20% rule as a precaution when they provide an estimate to a client.
Dimos Banis 