Do you get your QA to estimate story points separately?

[Gil]

A dev team may agree on a given complexity for a story, however, the effort of QA to test might be way higher or lower than what the dev team estimated.

How do you take into account the different complexities of testing and programming when estimating on issues?

In a previous place I worked, we summed up the QA and Dev. It worked fine, but I still wasn't sure if that's the right approach.

What are your thoughts?

[Jack Brickey]

I have employed two approaches, both of which involved separating out QA estimates. I never was successful in including QA estimates within a dev task and I don't believe that is the right approach.

• For any story/task requiring Dev & QA activities I created sub-tasks for each and had Dev and QA estimate their sub-tasks. This only works if QA can be completed within the same sprint since a story should be completed in a single sprint
• If QA is to be done post-Dev sprint, very common, I had dev working in the Scrum world and QA in the Kanban world. QA would have independent stories/tasks that were linked to the Dev stories/tasks. Bugs raised by QA would be linked (relates) to the original Dev story/task and, if desired, the QA test task (blocks).