Return to Answer

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.

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 them 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.

The project manager's is looking for an estimate of when the project will be finished, or if they are flexible on other sides of the time-function-cost triangle, what other leavers can be pulled to make it fit in to the time left. This is not unreasonable. Business decisions will need to be made based on this estimate. The problem is that is it really hard to estimate this. Planning poker is one of the ways to help with this problem. Most teams do not see it as simply adding together the number of story points, but rather a more complex function of estimating as well as you can, doing the work, measuring the time spent and extrapolating.

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.

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.

1. 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.
2. 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.
3. 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.
4. 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 and who underestimates and then you should share this with the team. People can help each other become better at estimating. Thiese numbers can also be fed back into your tracking tool to help better predict how long stories will take.

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 of which team member works on it and in what order the stories are worked on. The point is to get to a back log that is both prioritised, 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 your deadline. You should be able to stop at the end of any iteration and ship it with the features completed that had been started.

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.

The project manager is looking for an estimate of when the project will be finished, or if they are flexible on other sides of the time-function-cost triangle, what other leavers can be pulled to make it fit in to the time left. This is not unreasonable. Business decisions will need to be made based on this estimate. The problem is that it is really hard to estimate this for software. Planning poker is one of the ways to help with this problem. Rather than seeing it as simply adding together the number of story points, rather think of it as a more complex function of estimating as well as you can, doing the work, measuring how long it did take, iterating, and then extrapolating.

I find the most important part of story pointing meetings are the discussions that come up. If anyone in the team is not confident suggesting a number, then they probably 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.

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, with other factors affecting what number they give: e.g. 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 built then you can copy and paste, any worth while software project is different and so will have problems that you didn't foresee at the beginning.

As with time estimates containing hidden pressures, so a measure of effort also has issues. 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 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.

1. 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.
2. 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.
3. 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 on how long it will take you as there will be a hundred hidden assumptions in that statement that your stakeholder has that you won't find out until you show them something.
4. 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 and who underestimates and then you should share this with the team. People can help each other become better at estimating. These numbers can also be fed back into your tracking tool to help better predict how long stories will take.

I believe the point really should be the discussion, but if you really need to give someone a number then just try to make it one that is independent of which team member works on it and in what order the stories are worked on. The point is to get to a back log that is both prioritised, 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 your deadline. You should be able to stop at the end of any iteration and ship with all the features completed that had been started.

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 probably should only be used by people who are already experienced in using the other techniques.

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.

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:

1. 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.
2. 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.
3. 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.
4. 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.

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.

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 the estimates from other teams to provide an over all estimate on when all the stories will be done.

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 type 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:

1. 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.
2. 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.
3. 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.
4. 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 and who underestimates and then you should share this with the team. People can help each other become better at estimating. Thiese numbers can also be fed back into your tracking tool to help better predict how long stories will take.

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 of which team member works on it and in what order the stories are worked on. The point is to get to a back log that is both prioritised, 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 your deadline. You should be able to stop at the end of any iteration and ship it with the features completed that had been started.