Breaking user stories into tasks and estimating their development time in hours is pretty widely accepted. However, we have subsequent test activities that need to be carried out before the task and ergo the story can be deemed done.
Should the initial estimate for the development of the task INCLUDE man hours estimated to take the story to completion or should we have additional hourly estimates on the test tasks?
When you have dedicated testers it can appear to make sense to have a seperate testing task for them. But when you think about it, testing is really a team activity.
For example, a tester may need to speak to a BA or Product Owner to understand more about what they are testing. They may also need to speak with the developers to understand the new functionality. And of course they may raise bugs that need to be fixed by the developers.
I feel it is better to estimate tasks as a whole, including all that is needed to take them to 'done'.
In short: whatever works best for the team, the development process and getting stuff done.
Drilling down from the story level:
The story should deliver a fully workable product. If that includes testing in your Definition of Done or Acceptance criteria, testing is part of the story.
You can break stories down into tasks, if this helps development (everyone agrees in detail what tasks are part of finishing the story). Testing could be a separate task. You could also include testing in every task. You could even create a separate testing task, linked to each development task. Whatever helps the team getting the product done.
My personal opinion is that estimating hours for separate testing tasks, belonging to a development task, is too much in most cases. It's a lot of overhead, which would be better spent doing actual work. The complexity of the story and it's testing should be reflected in it's number of story points. Estimating very specific hours for testing tasks should not affect the overall complexity or time needed. Your situation may needs this or maybe not. It's impossible to say, not knowing what your team and process looks like. I do think it unlikely to have many benefits.
It depends on the team. Some teams have dedicated testers where it makes sense to have separate testing tasks since it can force devs and testers to explore the testing requirements. Other teams use XP practices or have dev/QA's where the majority of testing happens in line with the development activities.
Tasking is a tool to help the team explore the story in terms of tactical implementation. Assigning man-hours is on the lower end of the value scale of using tasking and is usually not a good reason to use tasking as it is a costly (in terms of time) activity.
I think it depends on who the intended audience is.
If the audience is the customer I don't think they would care much that it takes you X hours to develop and Y hours to test, only how long it takes to get the product to them.
If the audience is your internal project team, it can be a big help to separate the estimates for development and testing. If for no other reason it gives you data to be able to refine your estimates for subsequent sprints, allowing you to more easily identify where things are breaking down when (not if) you find your estimates are inaccurate.
Unless your Definition of Done excludes testing as one of the criteria, you must include testing in your overall estimates for the Product Backlog Item. Whether you treat testing as an implicit task or an explicit task is not prescribed by the framework.
Should the initial estimate for the development of the task INCLUDE man hours estimated to take the story to completion or should we have additional hourly estimates on the test tasks?
In Scrum, the deliverable for each Sprint is a potentially-shippable increment that achieves the Sprint Goal and meets the "Definition of Done." Your estimates for each Product Backlog Item (or user story, if you use that format) should always include everything required to meet all elements of the Definition of Done, including testing, documentation, validation, and anything else the team has agreed is required to ensure an increment is truly complete.
In general, elements of the Definition of Done are understood to be implicit aspects of each Product Backlog Item (PBI), and are simply rolled into the PBI's overall estimate rather than broken out as individual tasks for each item or user story. However, if you break out testing for each item as explicit tasks on your Sprint Backlog, then you should certainly estimate those tasks the same way as any other task.
This really amounts to an accounting issue. Ensuring that testing is accounted for in your overall estimate of the level of effort to complete a Product Backlog Item is a more agile estimation technique than the false sense of accuracy one gets from assigning exact hours to proposed testing tasks—especially since there's often a lot of ping-pong between testing and development in agile techniques like Test-Driven Development—but there's nothing wrong with estimating testing tasks explicitly as long as you are doing so consistently across all your Product Backlog Items.
The reason most shops don't do this is that if you're going to account for testing separately from development, then you should also have tasks and estimates for all the other elements of the Definition of Done as well. This generally leads to more process overhead, a false sense of precision, and is rarely more accurate than the aggregated estimate for a Product Backlog Item that implicitly incorporates the full Definition of Done.
Scrum views the entire team to work together on a single user story until it is done. To me, definition of done includes testing and ensuring that acceptance criteria is met. The entire team is responsible in getting the user story done and hence is liable to spend time on the user story. Therefore, testing effort should be estimated.
Also, in Scrum there is no role as "tester" or "developer". All fall under the category of team members. Since a team member (read tester here) will be working on a user story, her/his efforts should be estimated and recorded.
