“Estimation is what you do when you don’t know.”
This quote itself leads an individual towards positive and negative thinking for their business estimation. Some may think that estimating the time, effort, and cost required to achieve the goals is a better option to predict budgets. Whereas some may think that estimation is not so useful as this can’t provide the correct idea about anything and is based on the experience of the person doing it. A similar condition can be seen in an agile industry where it’s divided into two groups one who thinks estimation is essential and the other who consider estimation is not essential.
Here the question arises:
Do estimation is required?
The team who are against estimation mention some pointers as below to prove their say
They say estimates are mostly inaccurate so it’s useless.
They say that estimations are done not because they are important but because they are the part of the process for a long time
They say estimations are protected with a buffer which further creates mistrust and reduces transparency within the team and team members.
They say estimation should be considered a waste of time as they force teams to waste time and money for an estimation that is not even accurate.
Even though the above-mentioned pointers do make sense but still the business needs estimation as they need to justify their spending. The best example of estimation required is while the enterprise has to decide on the annual project budget distribution as it’s always better to fund more to the most promising projects.
But business should be never about taking sides. So it is better not to go deep in any of the two sides and consider estimation and no estimation as per the requirement of the projects. So instead of arguing about the estimation let’s see when should we way out for estimation for business benefits and when should not, to save time. We know that even if estimating or not estimating we need to be agile so let’s see how to estimate our agile user story progressively.
In our previous product backlog article we have already used the T-shirt sizing method to estimate epics and features it was a rough estimation as at that level we don’t have detailed and granular level information. Whereas, in prioritizing the feature we have broken the epics done into small user stories and created a story map. The steps we are taking at every level are refining the user stories in detail and granularity. This refining goes on also in the sprint where the user stories are again refined and split into tasks. At the point of release plan level, we can move into story point estimation. The story point preparation visit consists of :
Definition of Done (DOD)
One must confirm while defining the work done
One must ensure the DOD is exclusive for the team
It is not equal to the acceptance criteria as criteria are specific to each user story.
Reference stories
The estimation for user stories must have a baseline or some stories as a reference for using it as a benchmark. For creating a reference story we can use our prior set story map or can also use prioritized product backlog. Then we need to select and rank the five stories the team can align on considering the complexity, risk, and effort required. Once done, sum the ranking of each story and rewrite them in descending order. According to the assigned order, write down the Fibonacci scale for each story giving you the first five reference stories.
Swim Lane Bulk Estimation
To estimate the large number of stories it is better to use swim lane estimation from the variety of bulk estimation techniques. Using the same reference table we mentioned above which has a Fibonacci scale we will add another column naming swim lane in it. Selecting the story of the almost similar size and putting them in the appropriate swim lane of size. Once completed and discussed with it proper arrangement we can use it for release.
Mistakes Done While Estimating Stories
“Learn from the mistakes of others, you can’t live long enough to make them all yourself.” Keeping this in mind let’s learn what mistakes are mostly made while estimating.
Converting points in hours, as it provides a false sense of accuracy.
Averaging estimates, as it defines the wrong marking to the story.
Adjusting story points every sprint, velocity of difference sprint losing the velocity date required for driving process improvement.
Adjusting story points on basis of the assigned person, as it may dilute the estimation and confuse the further process.
About Advance Agility
We, at Advance Agility, are the new-age Agile Coaching, Consulting and IT services company. We enable end-to-end Digital Transformation. Agile execution is integral to our being. We are doing SAFe implementation with small, medium and large organization across the globe. Our vision is to be the leading Agile execution player globally. To keep adding value at every process stage. We are on a mission to empower our clients, move from concept to cash in the shortest sustainable lead time by adopting human centric approach to business agility. Embracing the change is in our DNA. Things that keep us apart are Quicker and Seamless execution with End-to-end gamut of services. Our Global presence and Stellar Track Record give us an edge over our competitor.
Connect with us at advanceagility.com to learn about SAFe and SAFe Implementation. Write to us at contact@advanceagilty.com for any agile training or consulting needs. We are always looking for competent agile trainers as well. So if you are a good trainer or want to become one, do get in touch with us to that we can learn, grow and achieve together.
Comments