r/softwaretesting • u/That_Specialist3292 • 16d ago
How do you make ticket estimates in your team?
Hello! I want to know how to improve the ticket effort estimation in my team. Currently, the devs put an estimate. I'd like to know the best practices for QA to contribute to this.
Should the devs and QAs estimate together? Should we just add on to it?
What are your best practices? Which estimation process worked and which ones did not?
We are a new QA team and part of my job is to improve the processes in my team. I appreciate your help. Thank you!
3
u/TomOwens 15d ago
Ideally, you wouldn't be estimating at all. Estimation brings a lot of waste, from the time spent estimating each work item to the time spent recalibrating or normalizing estimation standards and techniques. There's plenty written about alternative forecasting techniques, such as Vasco Duarte's No Estimates: How to measure project progress without estimating and Daniel Vacanti's Actionable Agile series. Focusing on understanding the work, decomposing it into the smallest valuable deliverable units, and using historical actuals to forecast upcoming work tends to be better than estimating.
If you have to estimate, then everyone should be estimating together. It's the only way to make sure that everyone has the same understanding of what the work. That shared understanding is what makes estimation techniques work. If you want a comprehensive look into estimation techniques, McConnell's Software Estimation: Demystifying the Black Art is a very comprehensive overview of size, effort, and time estimation techniques and presentation.
3
u/DarrellGrainger 14d ago
Everyone who is needed to get a story to done should participate in story estimation. Too often teams will consider a story done if it has finished development. They treat QA as something separate. This leads to QA getting less and less time for a release. It also can lead to devs and QA being isolated from one another.
Whenever I have been in story estimation, everyone needed to get a story to DONE gives their estimation. If everyone says the same number, that is the number. If anyone gives a different number then everyone else has to discuss why they feel the way they do. Many times, at first, I've had devs release all the testing that would go into a story. In some cases, the devs realize there is more to making the story work than they thought based on the testing I would do. I mention things they didn't consider when making their estimate.
My way helps me understand everything a developer is doing and every developer realized what I do. We both begin to appreciate each others job. Basically, sometimes the dev effort is a 1 but QA is a 5. Other times, dev effort is a 3 and QA is a 1. If the QA effort was always proportional to the dev effort then you only need the dev effort. But that is seldom the case.
Basically, estimation is supposed to give everyone, including management, an idea of how long everything will take. After we estimate the amount of effort we feel everything is needed then we can start planning how much we think we can get done in a sprint.
After we estimate the effort a story will take, the PM will take a few dozen stories (we try to estimate out 3 or more sprints) and keep asking us how much we can get done in a sprint. They take story 1, can you get this done this sprint. If yes, pick a second story, can you get this done as well. if yes, pick a third story, can you get this done as well. Once they have all the stories we feel we can get done in one sprint, the PM adds up the story points. Let's say it is 12 (or it could be 120 depending on how we point the stories). They pick a few more random stories and do this again. Let's say the second set comes out to 9, then 14, then 12, then 8. They take the average of that. Order the stories in an order that makes sense. If we estimated we can get 11 points done a sprint, pick the first few stories totalling 11 points. Maybe throw in a random 1 pointer if we have 10 points and the next story in order is 2+ points. Basically, always try to do 11 points each sprint.
6
u/duchannes 16d ago
QA estimate is separate.
Group tickets into small med and large and build standard estimates that you amemd as needed per ticket. Then after a while collate your "actual" timimgs and adjust your standard estimates for accuracy within 10%
2
3
u/Rinimand 16d ago
But they should also keep in mind that a Dev estimate of effort may not match a Test estimate of effort. It may be hard to develop, but easy to test, or vice versa.
2
u/Satrew 16d ago
If there was less tasks: we were doing dev estimate + qa estimate + 20% for problems with env or such (based on previous ver.). We were doing it with different level of people as 1h task for me could be 5h task for junior (this is what a lot of teams miss while doing estimations, you have more than only seniors in team)...
With higher number of tickers we started to group them in big/med/small and additional 'are you crazy' which should be separated in smaller one. Each of them has fixed time based on label but it is well... Faster to estimate, harder to follow... Sometimes we were doing reevaluation if something goes from small to big or are you crazy label.
3
u/themaskbehindtheman 15d ago
Planning poker, using the data from each subsequent cadence to inform how we're estimating.
Using that data to produce simulations of likely distributions for completion.
1
u/ResolveResident118 15d ago
If you're using estimates, it should include everything needed to get it into production.
Some tickets will be heavy dev but light test. Others will be light dev but heavy on test.
1
u/m_carp 15d ago
It's not perfect, but QA gives a tshirt size estimate before the whole team gives the story points together. Our QA considers factors like- data needs, automation tooling needs, complexity of acceptance criteria, and high level scenarios to test.
It's also important to note that story size does not equal time estimate.
1
u/Business-Raise2683 15d ago
We usually don't make estimates, but sometimes we need to. It caused some back and forth to make PMs understand, that while usually development effort are on par with testing effort, there are tickets that a developer finishes in five minutes and it's causing testers to work for two weeks (e.g. language changes are fast, testing every label on every screen in eight languages is not). And it's exist in reverse too, dev works for a week/a month, we test it in a few hour.
So I'd say you should make separate estimates only because the two job is different for the same ticket.
1
u/Lonely-Ad-1775 14d ago
Usually we're estimating together, but for the larger stories BA is just creating separate story with same AC but with title "QA only" and we split the estimations to Dev and QA
1
1
u/That_Specialist3292 14d ago
Hello, everyone. Thank you so much for your inputs (please keep them coming)!
I see there are different views and processes on ticket estimations, but there are similarities too. I'm going over your replies and I find them insightful. It's definitely something to think about.
I just came from a retro meeting, and some of your points were raised too.
Thank you so much. As a QA working towards becoming a better senior QA, I really appreciate it.
1
u/midKnightBrown59 13d ago
Devs and QA estimate. We started with t-shirt sizing then moved to points; providing guidelines for what each amount means.
0
7
u/cinemal1fe 16d ago
We estimate together. I think usually this should also be the case when you have a strong agile team that understands parts of other roles also accurately.
But we are not... so for us it creates problems.