When estimating effort for a user story, is tester supposed to estimate only the testing effort or the whole team effort?

If the story is technically challenging but relatively easy to test should I vote with a high or a low vote?

And vice versa, maybe it is easy to implement, but complex to test. In that case, let's say the developer and the analyst vote with 3 and I vote with 8, who would be listened to?

5 Answers 5


I think that estimation should be given by people who will eventually do the work. That means every role gives and estimate and you put them together.

It will always be a bit innacurate, but to me, it still seems much better than when someone else who does not do my type of work estimates how much I will spend on something. The room for error seems bigger in this case.

My personal experience is with two situations:

  • every role gives their own estimate, so as a Tester, I give an estimate of only my work, testing effort
  • Tester is not even asked for estimates, so everyone hopes (for the best) the Tester will not delay anyone for an unnecessary period of time

Scenario #2 really works only because I'm overly communicative when it comes to saying and promising when something is completed. So I manage to communicate more real estimates to the team even though no one really asks me. This approach also crumbles in many situations, but it's not completely up to me to change it in the company, even though I point this out every now and then.

So, to answer your question: based on what I think works better is a Tester estimating only their work (testing effort), and other people/roles estimate their work.


I think the effort depends on the definition of "done".

  1. If QA is included in the definition of done, meaning a user story is marked as done only if QA is completed then the effort should include both development and testing efforts
  2. If the definition of Done is "Qualified for QA testing" then only development and integration/unit test is considered
  3. If, you are working on a separate test user story, independent from the development process eg in TDD. Then the only testing effort is considered

We estimate in relative complexity using Fibonacci points, as a Tester I compare the following complexities to give my overall gut-feeling effort in points, compared to recent delivered features.

I consider the following, from top to bottom:

  • Testing complexity: How hard is test automation, do we have technical test debt, time to configure the system under test.
  • Functional complexity: How many steps, how many permutations, how simple is the workflow
  • Technical complexity: How many systems do we change, how many systems interact with this change.
  • Development complexity: How complex is our high level solution

We as a team all vote on complexity on the same time. If testers disagree with developers, it sometimes is because they did not take test complexity in consideration. I then explain what I think and then we re-vote. We nearly always take the highest number in the room of the second vote.

So I like it if the whole team, including testers consider the whole delivery in their estimation, but focus on parts that other roles might forget.

Considering only complexity and not hours does have it flaws. Watch the short talk: 7 minutes, 26 seconds, and the Fundamental Theorem of Agile Software Development. It is about essential complication versus accidental complication. I think this is also the reason that estimating software development is so hard.


Testers should not estimate effort only for themselves, but rather they should collaborate with the other members of the team to estimate the effort required to complete a user story. The effort estimate should take into account the testing effort as well as the effort required for development, analysis, and any other tasks that will be required to complete the story.

When a story is technically challenging but relatively easy to test, it would typically be voted with a high vote. This is because while the implementation of the story may require a significant amount of effort, the testing of the story will likely not be as time-consuming.

On the other hand, if a story is easy to implement but complex to test, the tester may vote with a higher number than the developer and analyst. However, the final vote would depend on the team's consensus, as each member's perspective and expertise is important for determining the effort required for the story. Ultimately, the team should come to an agreement on the final vote, taking into account all the perspectives and expertise in the team.


Yes, we generally provide effort in hours from QA point of view as well. Because when we are planning the sprint, we consider QA efforts as well in considering the user story done. It is a good practice that every one in the team provide estimates so that your proposed time line does not get affected.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.