Hi all,
I just joined a project which claims to be “agile”. However I am supposed to estimate the number of test cases and man-days that I will be spending on it.
Is this information even relevant on an agile environment? Is agile not supposed to be flexible enough? Am I seeing a “fast waterfall” disguised as "agile?
What are your thoughts about it?
Cheers 
Estimation is very relevant in Agile, but requires some different approaches so it doesn’t get in the way.
Number of test cases as a very poor indicator of quality or effort, so that is a huge red flag.
Agile usually encourages story point or t-shirt sizings as a low resolution estimation. The idea is to try and roughly keep work that is a similar complexity to have the same size. You use this to understand capacity on how much to bring into a sprint, or how wide to set WIP (Work in progress) limits.
Person days is usually another red flag and probably means the wrong question is being asked. The caveat is where you are working with a consultancy and the company needs to understand how to bill clients.
Generally, quality should be a “team effort” and stories shouldn’t be done until they are done and tested. So estimation for a story that adds or enhances functionality should include all team effort, including development, testing and anything else that is needed to meet your team’s definition of done.
Additionally, some supporting tasks like setting up frameworks or test stacks are probably good to ticket out.
Iterative development model that is followed by Agile SCRUM can end up looking a lot like mini waterfalls. This can be OK, provided the cycles are short and you get feedback from the bussing / customer frequently. Being agile isn’t about avoiding planning and estimation, it’s about working together to deliver small iterative value in close partnership with the customer, so you can course correct quickly and adapt to change.
There are a lot of flavours of Agile. There are also people who try to get better in Agile. The trick is to find some ways to improve the way of working. This can only be achieved by collaboration.
Let’s go back to the estimation problem.
The number of test cases is a classical way to calculate the man hours spent on testing. If it is difficult to use story points, then stick to the man days. In my answer I will use man hours.
The next question is: are test cases necessary?
I worked in a highly regulated environment, where my tests were audited. I used test charters and summarised my findings in the comment of the tickets. Of course it takes time to prepare charters and test data, but this time was less than time spent on making test cases. So my number of hours waiting for testing increased significantly.
Waiting for test execution has also an impact on the estimated number of man hours.
Suppose man hours and test cases are required.
Then make your best guess to estimate the number of man hours spent on a story.
The basic idea of a sprint is that most or all stories are done at the end of the sprint.
If you have a sprint for 2 weeks, then a tester has 80 man hours. Then all hours of meetings like standup, planning, and refining should be subtracted. Do not forget the man hours spent on waiting.
Say, this leaves 60 hours.
If the number of man hours for a single tester is more than 60 in a sprint, then not all stories assigned to this tester will be tested at the end of the sprint. In this case replacing stories in the sprint or splitting stories should be considered.
The first question that comes to mind is: who supposes that you have those metrics?
As for simply delivering those metrics, it depends a bit on the others of the question above.
If it is a case of “that’s what we always did”, well the agile manifesto says in it’s first sentence something about doing things yourself and helping each other. So simply change them if they don’t help you. Which is always a quick check for me how agile an environment really is. Can teams really change simple things like these if they want to or is there somewhere someone who has to approve?
If someone else, i.e. a stakeholder, wants those metrics, the real question is why do they want them? Chances are that it goes along the lines of “we’ve always had those”. In my experience as an agile coach it more than often boils down to two questions:
Do the metrics you are supposed to delivered help you with answering those questions? My out of context impression is that there is an implicit assumption of a certain amount of time per test case and that is used to try to predict the costs, while the man-days try to answer the delivery question.
Both are attempts that I would try to change.
First of all the questions aim only at a part of development, but I would put more focus on team aspects. I don’t know if you are doing scrum, but the scrum guide somewhere says that we want to deliver a potentiable shippable product increment at the end of the iteration, i.e. something that we are happy to give to customer to use. That includes coding, testing, delivering, writing manuals, etc.
It doesn’t matter who does which part, as long as it gets done, so a metric should IMHO be focussed on the whole process to put the emphasis there and not just a part as this fosters silo thinking in my experience. Long story short: Try to find out why they really want them and find some metrics together that might be more suitable (without knowing your context it is hard to tell, maybe number of testcases really makes sense. That would be an exception, but I have seen projects that were paid by number of test cases and for those projects the number was vital. You could argue those that the contract was bad 
)
Furthermore I would turn away from absolute estimations for two reason. First of all they suggest a validity that is not there and second: we as humans suck big time at them. If I asked you how high the Statue of Liberty was in meters and how he the Empire State Building was, the guesses would be going wild. If I asked you to tell me how high the Empire State Building was in relation to the Statue of Liberty, answer would be way better (about 4,5 times, I looked it up, though ). So using the anchor effect to establish a baseline is something to be very effective and is done as Ben has already described.
In the last few years I am also growing more fond of the #noestimates idea. Some teams are putting so much effort into estimation that it really cuts into their time with hardly any results. I have seen teams give sophisticated efforts of 573, 725 days with a confidence level of 67%. Which suggests a validity that simply isn’t there. The idea now is to not estimate at all. Some teams go for a simple classification of small, medium, big items and look back in time to say how long it took them to deliver those sizes. They then go on to give predictions along the lines of “for a small item we needed 2 days in 75% of the cases. 90% of the time we got it done in 3 days. If you want 95%, give as a week”. Especially I have come across this a few times in Kanban-environments and I kind of like it.
Hope that helps somehow and is not just philosophical in the morning
If they think that software development is a discovery and iterative process, where progress is done by quick feedback on small chunks of work (aka agile), I would first of all question why/how the activity of value investigation (aka testing) is based on predictive checks (aka test cases) and the idea that humans are interchangeable in such activity (aka man-days).