Agile - Estimating testing effort in hours instead of points

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 :smiley:

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 :smiley: but this is the “ideal paradise”

1 Like

The most important thing about estimates is to over-estimate your over-estimated estimation. :nerd_face:

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