Marcus UdokangProject Manager| Aivaz ConsultingCalgary, Alberta, Canada
In Scrum you estimate during refinement. If you estimate, it might be an indicator that you possibly need more detail in your stories. If the story estimates are too high, maybe they are not clear, or need to be split into multiple stories? Would like to hear your experience or opinion on high or low estimates, and how to get estimating right, or close to right as possible. Should we just not estimate at all? Is estimating crucial in dealing with the complexity and uncertainty of delivery stories? Saving Changes...
There is a healthy #NoEstimates movement out there. Estimating size of work items is still commonly done and that is used to extrapolate size of releases or entire projects. A better approach but one requiring higher maturity is to estimate throughput of similar small-sized work items and use that to extrapolate completion time for a release.
Kiron Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
I debated a lot with the "creator" of #NoEstimates movement in public forums and I demonstrated this: when you do #NoEstimates you are performing estimations. The first thing to ask yourself is: what does mean "to estimate"? So, you will see that each person in this world performs estimations from the time they wake up to the time they return to bed. If not, they are dead. As I stated time ago and it is my proud people have taken it in multiple papers and presentations: solutions are always created in the time they were estimated. But it is not the time people publish. That´s the problem. Lot of cases up there. The most emblematic I know is the case written by Microsoft itself about MS Word 2.0. And your life jacket: Barry Bohem´s work mainly "The Cone of Uncertainty". To estimate is a matter of attitude, no more than that. See @Scott Ambler blog about it inside projectmanagement.com when in the context of DA he wrote about estimations. A must read. Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Agree with Sergio,
we cannot avoid to try to estimate.
It is one way to obtain more security about a uncertain future, and our brain is permanently searching for this security.
Estimating is comparably easy, like how many minutes do I have before I should leave for work, my fuel sufficient to get there, how many hours at work is my free time etc. It is automatic.
So, you can try NOT to estimate, or not to share your private estimate, in order not to distract the focus of team members and yourself from other priorities and avoid biases. You still need to find security in other ways. Like trust the process (e.g. Scrum), shift (budgeting) responsibility to the sponsor, play randomized games.
Thomas Saving Changes...
Marcus UdokangProject Manager| Aivaz ConsultingCalgary, Alberta, Canada
Appreciate all the input, folks. This certainly helps lots.
Marcus Saving Changes...
Drew CraigSr. Agile & Product Coach| VanguardPhiladelphia, Pa, United States
Generally speaking, estimates are waste, never right, and can cause unintended expectations. That said, when using relative sizing, differences in valuations can facilitate needed dialogue on what exactly is needed for the work and ensuring alignment.
Teams can gain a level of consistency, and thus, some predictability within a window of uncertainty without spending unnecessary time estimating in time. This can be garnered through a variety of methods.
Estimating shouldn't be something you spend a lot of time on. I think in the very nature of business someone is going to ask for an estimate (ie, senior management) or you're going to need some kind of number for hiring/staffing purposes, but if you're spending a lot of time doing estimates - it's a waste of time. By the very nature of scrum, you're working in an uncertain space (if your work is very certain this is not the best methodology to use), and in an uncertain space sometimes you really DON'T know how long things will take or what will be involved until you get into it. Saving Changes...
Generally speaking, estimates are waste, never right, and can cause unintended expectations. That said, when using relative sizing, differences in valuations can facilitate needed dialogue on what exactly is needed for the work and ensuring alignment.
Teams can gain a level of consistency, and thus, some predictability within a window of uncertainty without spending unnecessary time estimating in time. This can be garnered through a variety of methods.
This is an excellent way to put it, Andrew! Saving Changes...
Rugpong GrachangpunProject Manager| A private Sector CompanyBangkok, Bangkok, Thailand
Hi Marcus, As I experienced, Estimation could be done in Agile too. But, I would say "unfortunately" it could not be done for long-term estimation.
Time and Cost estimation could be done on the stories which got refined. Those stories may or may not cover to the whole of project.
Base on the above scenario, what is a key disadvantage? I would say a big disadvantage is "How much money the sponsor need to invest in an Agile project"
I supposed myself to be an sponsor. If I was a sponsor, I would need to know how much do I have to pay for a project cause I need to prepare for the project budget. At the same time, a whole investment cost could make me calculate any numbers to complete the project selection process.
I my opinion, agile project is best fit to an internal project or external project when the client accept for unpredictable for the whole budget.
However, I may not 100% be correct at this. I'm open for any suggestion. I'm not quite sure if any fellows have a suggestion of that? Thank you in advance. Saving Changes...
Marcus UdokangProject Manager| Aivaz ConsultingCalgary, Alberta, Canada
@Andrew, @Susan, @Rugpong, much appreciate the responses. I do agree that the inherent unpredictability of Agile projects does make estimating a bit difficult at times, up to or beyond a certain point.
Marcus Saving Changes...
Andrew SoswaTechnology leader| Leading global financial institutionElk Grove Village, Il, United States
Is estimate a business priority (i.e. your firm must estimate a project for a government or external vendor buying creative service from you)? Then you must estimate by time/money.
If you work on internal projects, and you do not calculate CapEx or OpEx budgets then you probably don't have to estimate.
I think there is a huge bias of people who work on internal projects and determine that no estimation is needed (because they don't have to worry about budgeting or timecards), while at the same time, vendors have bias to spend too much time estimating everything (because every hour is billable) Saving Changes...
