Our dev team estimates work in hours, but we do not include any testing time in the original estimate. For example if the devs say an item will take 4 hours that will become our estimate for that item, but it might take an additional hour for our QA team to test. Do you add that hour to the original estimate of 4 hours making it 5 hours?

Please include as much detail in your answer instead of just saying yes or no.

Also, please don't suggest to use story points as this did not work for us.

  • 2
    The way you phrase the question implies that you are expecting the answer to be yes. What are you trying to accomplish with including/excluding QA testing hours in the original estimate? What decisions do you make based off the original estimate? Why didn't story points work for your team? Are you phrasing your question in terms of running an Agile-Scrum team?
    – WBW
    Commented Jan 20, 2015 at 20:08
  • @WBW I think you are way over thinking my question. I am not expecting the answer to be yes. I am expecting an explanation behind the answer. This was meant to be a simple question with a simple answer which I have accept below as he has explained a reason of why I might include testing in our original estimate base on what we consider as done. Commented Jan 20, 2015 at 21:31
  • 2
    Story points are complexity. If you use story points, you are suppose to also use estimates for time, they are not mutually exclusive. Also you then can start to understand when complexity of "8" is chosen from your past sprints how much time was estimated versus actual. At that point if your team estimates "8" you look and see oh on the average that is 24 hours of work. Story points allow for relational time comparisons easily because without them estimating pure time is going to be moot and not any better than guessing 2000 hours because of the uniqueness of each item of work.
    – Shawn
    Commented Jan 22, 2015 at 18:52
  • Quick answer: It depends What are you using the estimate for?
    – Philipp
    Commented Jan 29, 2015 at 6:38

10 Answers 10


The estimate for an item should cover how long it'll take to be done. Assuming what you define as done covers testing as well as development, then it should be in the original estimate.

The best way to ensure everything that needs to be covered to reach done goes into the estimate is to ensure everyone involved (eg the testers) are invited to the sprint planning meeting.


A quick counter question can probably answer this. "Would you deliver to the client after 4 hours of Dev?"

Since you can't deliver after just the dev work, QA's estimate has to be included to the original estimates.

As @David suggested, you should go for the Definition of Done which includes every activity needed to complete the job from initiation to delivery.


A few things to consider:

If the QA finds a bug then the developers have to fix it. Then it is likely the QA will need to re-test to confirm the bug is fixed. So simply saying that the QAs need 2 hours can be quite misleading. Testing impacts on both the developers and the QAs.

If your QA resource is limited and you want to estimate in time units then you need to consider not overloading or underloading the QAs. For example, saying you have 100 hours of development work and 100 hours of QA work only works if you have the same number of developers as QAs.

These complications are why a lot of people prefer to use story points. Story points are an estimate of the relative complexity of the story rather than the time you expect each discipline to spend on it (which is very difficult to guess correctly).

  • Thanks for your comment. We do not have as many testers as developers and what you're saying makes a lot of sense, but what do you do to track your testing time if you do not include it in the original estimate and if you don't consider an item as done until QA tests it? Also, i don't understand how story point can be better when neither can be accurate estimates every time. if you estimate in points how do you know when an item is going to be completed if your not working in time? Commented Jan 29, 2015 at 20:40
  • 1
    The idea of story points is that you learn from your past performance. Say, for example, a team does 20 story points in a sprint, then 22 story points in the next sprint, then there is a good chance they will do around 20 story points in the next sprint. The accuracy comes because it is easier to estimate the relative size of stories than it is to estimate the time it will take to do stories. And you are basing your estimates on real data, how many story points you achieved in the past. As teams get more used to story points they get better and better at relative sizing. Commented Jan 29, 2015 at 22:28
  • 1
    Now the developers might say a story is a 3 point one, but the testers then say "that is difficult to test, let's make it a 5 point story". After a while the team gets used to what it can achieve in a sprint. Commented Jan 29, 2015 at 22:29
  • Empiricism - it's what Scrum is based on. Hours are rarely correct due to the number of variables. Story Points are an abstraction of hours based on previous knowledge/experience (empiricism). Commented Sep 26, 2018 at 15:20

QA estimates must be included in the original estimates, because QA activities will also consume time and impact the project completion milestone.

Development estimates are for the development team, and QA estimates are for the SQA team. We include both development and testing time in the estimates, but separately.

If we merge them - - We cannot identify the estimates for development and QA separately. - We cannot compare the estimates with actual time taken for development and QA separately. - We cannot have separate milestone development complete and QA complete. - We cannot track development and SQA progress separately.

Development and QA are (mostly) done by separate teams, so it is better to separate them.


The estimate from the development team should include time to perform automated testing. In addition, time should be estimated for a release QA period. Additional resources should be accounted for in the release QA period for user experience testing.

My team has found this to be very helpful throughout multiple projects. The automated testing, generally completed through test-driven development, catches issues throughout the normal development cycle. Our User Experience Specialist performs release testing with test users during the release QA period to discover anything not caught in the automated testing.

Having designated release periods for user experience testing also frees up the development team to add polish to the application and incorporate learnings from the user testing that are within scope.


The simple answer is that the scope of the tasks should be made clear, e.g. code, unit test, test, QA etc and then you will know where to allow for testing and all other efforts in your estimates - and if coding is expecting to include an element of testing by the programmer, then this must be included in their estimates


We include testing that will be performed by our devs in our estimate (eg, writing tests for TDD, writing additional unit tests or feature tests for our nightly regression tests).

We also discuss the type of testing that will be performed by the QA team, and the likelihood that they will find problems that we will need to fix (which tracks with various types of complexity or cosmetics). We estimate the amount of additional dev time that will be required to support or iterate with the QA folks, and include that in our estimate.

It's often useful to discuss things from the perspective of the testers, since that may cause us to realize there is some additional complexity, and revise our original dev estimate.


It doesn't actually matter in normal sprint planning as long as you are consistent, i.e. using yesterday's weather (i.e. velocity) to plan, or if you do some sort of traditional capacity planning instead, then you would exclude the available test capacity if you also exclude test from the estimate.

If you are making an offer on a time & materials project or something, you probably do want to include test effort, unless know test costs are being covered with some buffer or something.


In my opinion, the key is to focus on the 'Definition of Done', mainly from the perspective of the Product Owner. Now the team (cross functional team to be more precise) may have some (or a lot of ) questions which needs to be hashed out between the team (remember I am not saying the Developer or Testers) and the PO, so that they have a common 'Definition of Done'. This is where the skills of an experienced Scrum Master come into picture. He/She can really orchestrate the discussion so that both of them find the common ground. Btw, the appropriate place for such a discussion is Sprint Planning meeting.


Quick answer: YES

Always factor ALL the effort your team will need to commit towards a story or piece of work, regardless of the estimation technique used. How you do testing, etc., should be a part of your Definition of Done, and your estimates should reflect that work.

Sorry for grammar/spelling I am on mobile -

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.