Do any of you use hours in estimating testing effort? Has that worked well for you?
PS - Honestly, I never understood estimates in terms of points or hours. I just guess and hope it will work out well.
2 Likes
The estimate for an item should cover how long itāll take to be done. We always estimate in hours because itās probably the most easiest thing to do.
Story points:
Ticket A is a higher effort then B so ticket A would get more story points then B.
Ticket C is a higher effort then B but lower then A so it would get an amount of story points between A & B.
Depending on the way of working, you can give story points accordingly. Some people say 1 story point = 1 hour, some say 4 hours and some a full day.
So estimating 4 hours or 4 story points isnāt that much of a difference, as long as the team knows what it means.
Estimates can rot in hell if it were up to me. Why? This tweet explains it better in one picture than I can in a 1000 words
This is about stories but applies to estimating testing too. The outcome of testing can vary wildly and is impacted by so many thingsā¦
This ācreating software is like a factory process and thus estimatableā has got to stop lol.
1 Like
I think thatās just bad planning? You can surely say it will take me 4 hours to make/test. But yea people have vacations, bugs show up etc etc ā¦ . What happens in reality is you have a 40 work hours a week and people tend to put 40 or 50 story points in a sprint for 1 person. Which is wrong in my opinion.
We only put 20-30 story points in a sprint per person, specifically for the reasons in that tweet and if they arenāt doing it like that, wellā¦ , in my opinion, they are doing story-point-planning wrong 
And even if it takes you longer, thatās ok. Thatās the point of story points, you reassess the time-value of a story point or the weight of a ticket and adjust accordingly. Thatās the real āagileā people talk about and not just āletās have a stand-up & lets do a retroā.
Donāt get me wrong, I also hate giving estimates but this is the āideal paradiseā
1 Like
The most important thing about estimates is to over-estimate your over-estimated estimation. 
2 Likes
The Scrum guide has nothing on Story Points. It has elements about āestimationā but it doesnāt say how.
Somehow, story points ended up as āthe standardā. That is not āreal agileā, whatever that even is.
" Although Scrum Teams should apply some sort of āestimationā, there is no mention of Story Points, hours, ideal days, gut feeling, t-shirt sizes or any other unit for that matter. The Scrum Guide does remind us to use an approach that respects the complexity of software development and to not let estimation replace the importance of empiricism itself ." (from: Myth 9: Story Points are Required in Scrum | Scrum.org)
And somehow, these story points are āhoursā for a lot of people. But IF you want to use estimates, use complexity relative to other work that the team has already done.
By estimating testing in hours, you are opening yourself up to the anchoring effect. āBut you said 4 hours, why are you taking longer?!ā - some manager, probably.
The whole idea that we are good at planning software development work is laughable, in my opinion. āA plan only survives until first contact with the enemyā - General Moltke. And in IT, those enemies are complexity, risk, uncertainty.
Maybe Iām too much of an anarchist when it comes to āagile processesā as I believe most of it can be tossed in the bin. Itās all a fruitless search for an illusion of control. I prefer to not use estimates at all, but a Kanban process where you work on one thing at a time. That one thing takes as long as needed, and then the question is more āis it worth itā. But yeah, Iām used to the fact that my preferred way of doing things goes against the grain. Thatās ok. Rant over!
2 Likes
āPlans are worthless, but planning is everythingā - Dwight D. Eisenhower
- Plan for how much time X will take will lead you down a dark path. Planning for what to do when you run out of time, which things to drop first, is far more valuable.
- Plan for how risky some X will be will only work for ārisksā that you already know. Planning for risks that you do not know yet, for instance how to revert the application to the last stable/ācorrectā state, could be useful in the future
- Plan for how much something is going to cost (money & resources) will always be missing some cost that we do not know of, yet. Planning to not commit everything yet, so you can adapt the plan when these costs become known: you will be glad youāve been planning ahead instead of having a plan that documented how much each part is allowed to cost
Whether you plan in hours, story points, t-shirt sizesā¦ you will always get something wrong. And you will probably explain it by āwe need to become better at estimatingā, instead of accepting that we cannot predict the future: we can only prepare for it.
I provided testing estimates and an expiration date on the estimates. Usually, my estimates go stale within a day or so.
I much prefer to work on an important (defined by someone) task until it demonstrates some level of (defined as MVP but Iām flexible on that) value. Build on small successes!
Joe