Why is an estimate required ?
An estimate on a task, story or a feature is really required to answer 2 questions
a. How long is it going to take to build it ?
b. How much is it going to cost ?
Who really needs estimates ?
In a typical software project, there are 2 kinds of people who really ask for estimates.
1. Product Owners – They are the ones who care about what is being built in the product. When they look at an estimate, they are thinking
a. Can I really wait this long to get this feature out to the market ?
b. Is it worth building this feature given the cost ?
c. Can I come up with a cheaper option which can give me a better return on investment ?
2. Managers – They are the people who are responsible for managing the budget allocated to build a product, and also schedule dependent activities based on delivery timelines. When they look at an estimate, they are thinking
a. Will this feature be delivered within budget ?
b. Can I make commitments to other stakeholders, dependent teams, schedule other activities based on these estimates ?
Issues with estimation
1. Time taken to estimate
Teams spend significant amount of time during the project to estimate and come up with accurate estimate numbers so that project managers can plan and make commitments. This takes even longer when you are estimating in hours or days instead of light weight metrics like points.
Some project teams have multiple reviews of these estimates and even bring the estimate down to a complex formula which is worked out based on over 5 parameters for every story. A lot of time is also spent in deciding which estimation model to use in the variety of estimation techniques available in the market.
2. Accuracy of estimates
The more upfront estimation is done for stories, the less accurate the estimates are. Estimating stories which will potentially be played 3 months down the project makes no sense because a lot would have changed in project, from the codebase to the team composition which will ensure the upfront estimates are stale. Ultimately these stories will have to be re-estimated which will again consume equal amount of time if not more, after 3 months.
3. Undue pressure on the team
Estimates which are done especially in hours or days end up putting undue pressure on the team members. Inexperienced managers push their teams to achieve the planned velocity by making them work for longer hours which ends with a team death march instead of working in a sustainable pace.
4. Time wasted in questioning estimates during the project
A lot of time is also spent questioning estimates of individual stories in the project when things are not going too well and the project is not on track. Stakeholders as well as managers start questioning estimate of stories which have a larger number against them. Some people start measuring actuals on estimates which is counter productive.
Reducing focus on estimation
1. Engage with the right stakeholders
More than the estimates themselves, it is important that the estimates are being given to the right stakeholders.
Engage with the people who
a. Care directly about the product and the features getting built in it
b. Are directly responsible for the money being spent to build that product
It is often difficult to achieve this in large organizations which do In House IT development with multiple vendors such as banks and insurance companies. It is often easier to get the right stakeholders in a product company or a start-up.
If you are reporting estimates and progress to someone who is just a middle manager not worried about either of the above, the you are engaging with the wrong stakeholders and are wasting your time.
2. Engage with stakeholders by showing working software than status reports
Once you have the right stakeholders as talked about above, it is important that you move the engagement by showing working software frequently rather than showing status reports with estimates and burn up charts. Show progress by showcasing new features built by the team to the product owner rather than showing how many points were completed.
Release as often as possible. Achieve a monthly , weekly or even a daily release cadence. Once people who pay the bills, see the releases coming out, they will worry less about velocity in iterations.
3. Be transparent about the processes and practices
Stakeholders start worrying a lot about estimates for each story when they are sceptical about the way the team works. Some people start looking into the estimate of each story and question the estimate, and the team spends hours justifying their estimate. This often happens because stakeholders do not understand that the team works on a pull based work schedule where if a story gets done , the team pulls in the next story to work on, and estimates largely become irrelevant during execution. (E.g.: even if a story is given a questionable estimate of 4 points, if the team completes it within 2 days instead of 4 days, and agile team will pickup the next story from the card wall )
When stakeholders understand this model of work distribution, they know that there is minimal waste of team capacity and stop worrying about estimates. Measuring actuals in such a scenario is also a compounding waste.
4. Use relative sizing of stories when there is a need for a rough timeline and cost
The question of “How long is it going to take and how much is it going to cost ?” will always we be asked for stories, features and product releases. Someone will have to signoff on a rough budget to build the product and commitments will have to be made to people dependent on the product launch. This demands some sort of raw estimation and scheduling of work.
Given the nuances of detailed estimation, a better approach is to use relative sizing using story points and either use raw velocity or yesterday’s weather for planning.
5. Focus on reducing cycle time or business value delivered if a KPI is needed for progress
There might be situations when a metric is required to track progress as a team, and if that is required, focus on reducing cycle time to delivering stories to production. Another good indicator is the amount of business value delivered in a period of time by the delivery team.
Conclusion
Software industry has moved from an era where teams did upfront analysis and design for a quarter of a year before development began, to a much more iterative development model quicker release cycles since the wide adoption of the Agile manifesto. With the advent of cloud computing and continuous delivery it has now become cost effective to deliver frequent releases to production every month/week/day. This has left software estimation irrelevant over a long term. Estimates will still be required to give a budget and a date commitment to clients, but with there exists a strong case to focus lesser and lesser on estimation.
No comments:
Post a Comment