Consider the Project Manager's point of view
By asking for complexity they want a number that they can compare with your next sprint to find your velocity as a team. They may also be trying to use it to add together your result with other teams to provide an over all estimate on when all the stories will be done.
The discussion is more important than a number
I find the most important part of story pointing meetings are the discussions that come up. If everyone in the team is not able to feel confident suggesting a number then they don't fully understand the story and there needs to be more discussion. From the Agile Manifesto "Customer collaboration over contract negotiation". Rather than just specifying a contract written as a user story and saying the team failed if they don't do exactly what you want, it is always better to talk about what the customer really wants until you understand it.
Complexity Vs Effort
To address your specific question about complexity vs effort, everyone seems to have a different opinion on this. Mountain Goat, who are the people who make the planning poker cards that have goats on the back of them and whose owner Mike Cohn is big in the Agile / Scrum world, say that it should be effort and not complexity.
It is normally not seen to be a measure of time, see example below for a counter example, as people are bad at estimating time, as other factors affect what number they give, pressure to keep the number low so you can fit more features in, pressure to give a higher number to give yourself some room if you run in to a problem. Building software is hard. When you build your 100th house you can estimate how long it will take you as you have built 99 houses before that. If the software you are building is the same as previous programs you have build you can copy and paste, they are always completely different and so every one will have problems that you didn't foresee at the beginning.
As with time estimates containing hidden pressures so does a measure of effort. If a junior developer estimates a high complexity they may feel they are leaving themselves open to attack as not being good enough from others who would give it a lower estimate. This is not only detrimental to your estimates but to the people on the team.
The planning poker numbers are not 'number of days' or some other measure of time, they are a relative measure to be able to compare two user stories. The first thing you need to do in a new team is to establish a baseline. Pick one user story that is in the middle of the complexity range somewhere and agree as a team a number in the middle of the range that you want to assign it. Now all other user stories can be numbered relative to this one. I have found this makes it much easier.
Reasons you can't give an estimate
When project managers ask you for when a project will be done they need to understand the complexity of the question they are asking. Programmers are not factory workers, where their productivity can be measured by multiplying how fast they types by how long they work. They are figuring out answers to problems and that is hard. By playing planning poker you first identify who in the team feels they can't answer the question of which number to assign and then you dig in to why they can't answer that question. I think there are at least four reasons:
- The story is too big. Break it down into smaller more specific user stories. Remember each user story should be providing one piece of value to the user; input - process - output = value.
- They don't understand the problem domain well enough to be able to say how long it will take them or even ask all the questions properly. Go talk to people who do know more about the stakeholders domain / programming that kind of application, whatever it is you haven't seen before. If that is not possible or doesn't get you all the way there then you can use a design spike. Go and prototype a solution but only for a limited and specified amount of time. Define how long the prototyping phase will go on for, not too long, and then meet back up again to share your new understanding.
- Your stakeholders are not being specific enough. "Build me a cloud" is not an acceptable user story. "Build me a system where I can spin up VMs on demand" is better as it is broken down further but is still not at the level where you can give an accurate estimate as there will be a hundred hidden assumptions in that statement that your stakeholder has that you won't find out until you start building it.
- Finally, even if you can give an estimate it will probably be wrong the first time. Estimating is a hard problem and the best way I know of to solve hard problems is to use the scientific method. Collect data on what numbers each team member estimates, then collect data on how long it really took them, or how 'complex' it really was, although that is harder, and then compare these over time. Eventually you will get a feel for who overestimates, who underestimates and then you should share this with the team. People can help each other become better at estimating.
Conclusion
I believe the point really should be the discussion but if you really need a number then just try to make it one that is independent on works on it and in what order the stories are worked on. The point it to get to a back log that is both priorities so you are working on them in the right order and sized so that the Project Manager can see roughly how many more you can fit in before some deadline. You should be able to stop at the end of any iteration and ship it with the features completed that had been started.
Warning
You can estimate time to complete tasks within your team as much as you want as long as you keep the numbers to yourself. Once you allow any number to escape the team and be seen by other people they will do things with that number that you did not intend. They will try to use it as a number of days to complete the tasks. They will try to hold you to the relative complexity rating and ask why it took you longer to complete one user story than another with the same number of points. They will add your numbers together and compare then to other team's numbers and ask you why the other team is 'doing more work' as they complete more story points within a time period. You can't stop this but you can keep open lines of communication with all your stakeholders and try to set their expectations as close to your understanding of reality as possible.
Aside
The planning poker set of numbers are normally distributed such that the gaps between the numbers keeps getting bigger. I believe this is meant to discourage people from arguing over whether a user story is a 16 or a 17, if it's bigger than a 13 then just make it a 20.
Example
I know of at least one team that only uses the numbers 1, 2, 3, and 4 for planning poker. They, against convention and contrary to the discussion above, define these as programming days (actually pair programming days, that is how many days it would take two programmers working together at the same machine to complete the user story). If the team thinks it would take more than 4 days to complete a user story then it is left not story pointed and the product owner is asked to work with the team to break the story down further or to specify it more exactly so that it can be brought within this range for a future planning meeting. But this is advanced agile and should only be used by people with experience of it.