Table of Contents:
As many as 75% of software projects will fail, according to a study published by Geneca.
This is in large part due to difficulty in making estimations of things such as cost and scope in software product development. Humans, for all their doggedness, are almost comically poor at predicting outcomes that are absolute.
There is no such thing as "accurate estimation", which is an oxymoron, if a common one. This is where agile estimation techniques step in.
Agility is, above anything else, a mindset, rather than a set of clear-cut rules. It is a gateway to handling, and ultimately thriving in, an environment where turbulence and uncertainty are the norm.
The idea of agile estimation was birthed in the 'Agile Manifesto', a document written in 2001 by a group of seventeen software practitioners. The manifesto outlines four values and twelve principles (including "early and continuous delivery of valuable software" and so on) for agile application development.
The four values are:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Creating excellent software products can be a daunting effort for everyone involved. When it comes to software development, estimations, whether of cost or time taken for delivery, are part of the daily routine.
Each project is different, and issues that seem simple in theory can in fact be hard to implement. Furthermore, every person has his or her own skillset, experience, ability to adapt, and so on. Clashes and other problems are bound to arise, sometimes unexpectedly.
Agile estimation aids in the decision-making process and encourages strong coordination. Fewer defects result in higher value and slashed delivery times. With agile methodology, you can undertake careful management and planning, deliver the ideal product, and strengthen ties with your customers.
Coordination: Your success is determined by how well your team works together. It does not matter how high-tech your tools are if there is little effective communication.
Risk Management: Insights into your project's risks boosts the chances of its success. You can determine features that are risky and address them.
Informed Decisions: Getting an idea of the benefits and costs will help you make better-informed decisions. This in turn will allow you to predict challenges and opportunities down the line.
For agile development, the product owner must prioritize the backlog, that is, the list that has descriptions of all required fixes and components for a product. Fractionating work items into estimates and pieces through "story points" aids in prioritizing all parts of work, including ones you might not expect. A story point is a number that indicates the difficulty of a story, whether it is regarding risk, effort, or complexity.
There are primarily seven agile estimation techniques:
Planning Poker: It is an ideal technique when a small number of items is to be estimated by a small team. Members of the team create estimates by playing numbered cards facedown on the table.
The estimates are discussed after the cards are revealed. This is done to avoid cognitive bias. Numbers are important here; a story at a 6 should be three times as difficult as a 2.
The people with the highest and lowest estimates reveal their thought process for choosing their scores, and those with expert knowledge might inform the team why a particular story is in fact easier or more difficult than originally thought.
In this method, everyone gains a better understanding of the process of estimating stories within and outside their field. This is the most well-known technique and makes sure that every team member's voice is heard.
The Bucket System: The team estimates items by putting them in "buckets". It uses the same sequences as Planning Poker but is a faster technique than due to the "divide and conquer" phase, during which members place items on the scale without talking about it with others first.
If someone thinks an item should be elsewhere, they can bring it up. Instead of giving absolute estimates, it gives results that are relative. It encourages teamwork and accountability of the group as a whole, since results cannot be traced to individuals.
This is a good system when a small to medium team is estimating a large number of items.
Dot Voting: This can be considered a tool for decision-making rather than an agile estimation technique. It is, however, an effective and simple method for estimating a small number of items.
This method ranks items on the basis of priority. Every person get a number of "dots", which are used as votes to determine the size of the items. Fewer dots mean a smaller item, and so on.
Big/Uncertain/Small: A fast technique for when you are short on time - it is a simplified version of the Bucket System.
The items are placed in one of the following categories: big, uncertain, or small. The team starts by discussing a few of the items together, and, like in the Bucket System, use divide and conquer for the rest.
Affinity Mapping: Items are clubbed according to similarity, establishing the sizes of stories. This should be executed with visuals. It is an ideal technique if a project has just gotten off the ground or there is a backlog that has not been estimated yet.
It is a collaborative exercise and can be considered less "confrontational" than other methods. Stories are arranged horizontally in ascending order, and the team may decide to change the size of a story.
Ordering Method: On a scale that ranges from low to high, items are put in an arbitrary order. Each participant takes turns to make a "move", which involves discussing an item, passing, or changing an item's position by shifting it on the scale. The ordering is complete if everyone passes. This method gives the priority in addition to the sizes of order of the Product Backlog items.
T-Shirt Sizes: As the name suggestions, items are categorized according to T-shirt sizes: XL, L, M, S, XS. It gives you a rough estimation of a large number of backlog items. After estimation, the sizes can be given numerical values, if required.
Choices about size rely on openly talking about them. The upside to this is method is that you can think in a more abstract way about labour, and it brings out the creative, more whimsical side of your team. However, bear in mind that what is S to someone might be M to another. This is a fast process, but it might shrink the accuracy of estimates.
This method also requires more work from the person coordinating it, since the sizes need to be given numerical values for tracking estimated velocity. Overall, this is a good method for teams just starting out with agile techniques, though it is advisable to eventually shift to a more precise method.
BluEnt is your trusted partner for web application development. We use the Scrum framework to implement agile principles, leading to cost control, increased revenue, higher quality, and customer satisfaction.
From designing prototypes and wireframes to make a creative storyboard to outlining an intelligent app strategy, we refine your app before diving into agile estimation. We iterate until you are satisfied with the outcome for your app. Contact our friendly and experienced agile app development team now to know more.
Maximum Value. Achieved.