Please login or join to subscribe to this thread
Agile estimation, just like any other types of estimation, takes practice. The more that it is done, the better the developers will get at it. Repetition and experience is key.
Just remember to recognize and reward when actual performance is close to the estimates. We often only reward for coming under our estimates. That leads to padding.
@Stephane, rewards for being close to the actual estimation? That's new.
That was part of my performance objectives at EDS. If my actuals were within 10% of my estimates, that performance metric was satisfactory. To get a superior, I had to be within 5% of my estimates. Remember: that's within. You can be higher or lower, but you must be close.
Of course, that performance metric was balanced with others to avoid gaming the metric.
Thanks Stéphane. All useful. Will give this some thought.
The Estimation technique we used was relative estimation. I explained the idea of relative estimation to the teams & we all agreed & created standard user stories with story points of 1, 2, 3, 5, and 8 each so that the teams can compare these standard stories & relatively estimate their respective stories.
Software development is a highly creative activity which makes it impossible to accurately estimate the effort needed to complete a certain task. Of course more complex the task is less accurate the estimation will be, and for the less complicated tasks there are better chances to give a more accurate estimation.
The best person to give the best estimation is not always the most experienced developer but the developer who has worked the most on tasks similar to the ones that have to be estimated.
No matter what methodology is being used software development estimates will never be as accurate as the estimations made in other activities.
Another important thing to understand is that some developers may give shorter estimations but the code that they produce will not be well optimized, may have a lot of bugs and can results in a lot of technical debt. The race to complete software development tasks in less time can be disastrous for the project as it can result in a poor buggy product or in a product that will be hard to change in the future (technical debt).
Also I believe that people that have never worked with the technology that it is being used for the project or for the product being developed or worse those that have never written a line of code in their lives should as much as possible stay away from software development effort estimation as they will bring no real value to it.
Many times developers find out during the implementation of a task/user story that the estimation is wrong but they still manage to finish the work in time at a a high cost: many bugs, less efficient code, and a lot of technical debt that will make future changes time consuming.
This is an intriguing question. Would you be able to provide more information regarding your team's estimation struggles so that we can provide a more specific advice?
I wasn't sure which agile framework you are using but you did mention "Story Points" - so I made the assumption that you are using Scrum and are using Planning Poker.
EXAMPLE kinds of struggles:
1. Are your team having difficulty converging their estimates? During Planning Poker, is it very commonplace for someone to vote 2 points while another person votes 20 points for the exact same story? Do they have trouble agreeing on a converged estimate even after lengthy discussions?
2. Are your team pretty good at arriving at converged estimates for a story, yet finding that they are inconsistent with the scale? Does a 2-point story very often turn into a much bigger piece of work than a 5-point story? On the other hand do they often vote 20 points on something only to discover that it is actually a very tiny piece of work?
3. Are your team actually excellent at both points #1 and #2, but are often over-estimating how much they can do in a single sprint?
IF the problem is #1: This could often be due to inconsistent/unclear acceptance criteria, resulting in every team member having a different "definition of done" in mind.
IF the problem is #2: The team may be unfamiliar with the technology stack involved in the project, or the tasks at hand, and are having difficulty drawing comparative estimate to other similar things they've done previously. This may be helped with technical training
IF the problem is #3: Sometimes a team can be persistently optimistic and ignore their actual observed velocity. This can be cultural, or they may be under pressure from an unrealistic Product Owner.
Having said that, it is completely normal for newly formed or reformed teams to go through a 'calibration phase' (anywhere between 2-8 sprints or even longer) where Story Points feel all over the place. But you can expect that after a while they should become better at estimating. If the estimating quality issue is chronic then there is an underlying problem which you must address.
Recognition and rewards are all good stuff and will motivate them to constantly look out for opportunities to improve... however as their project manager/Scrum Master it is absolutely imperative that you provide them with the support and tools to do so.
There is only so much I can write here so feel free to PM if needed!
Interesting concept of rewarding someone for right sizing the estimation. I agree with the comments of estimation takes practice. We have devised and agreed upon a Train level assessment where 1 point = 10 hours of work; this helps translate the actual work and also in budgeting and financial calculations (different topic).
Estimation are done collectively as a team and the team should be rewarded as a whole. It surely helps in keeping the team motivate to continue to improve and correctly assess their work. Invariably, it rolls up into one of the roles of a Scrum Master to improve the team. So Kudos to you!
Please login or join to reply