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

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.

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

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

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

Conclusion

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.

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

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

I think Frank’s and Encaita’s answers pretty much covers it but there are some additional things to consider:

Why use story points

The aim of estimating with story points is to give the relative complexity of developing features for your application. A simple way to think about it is take a story you have in the upcoming sprint e.g. a url change. You know this is simple in terms of complexity, and has clearly defined acceptance criteria so the whole team agrees that even with testing it’s a 1 (using the Fibo scale).

The next story to be estimated is aggregating a set of user data and visualising that on the front end. Now as a developer you know immediately this is way more complex than changing a url. You discuss the story and the acceptance criteria and you have a lot of questions and can see several potential solutions for doing this. The other devs and QA also agree it’s very complex. So you all agree that it’s a 34 point story. It’s worth noting that the Fibo scale also allows you to indicate how much confidence you have in the esimate – the bigger the gaps between numbers indicates the less confidence you have in your estimate

At this point your Scrum master should jump and say that this as a single story is too big and needs to be broken down into smaller stories of less complexity. You can approach this by doing what are known as SPIKES – this is just some time set aside to investigate something. So for this example you and the other devs agree you want 4 hours to discuss and investigate the possible technical solutions.

To cut a long story short you break that big story up into four other stories of 5, 8, 8 and 13 points. No remember that these estimates are all about relative complexity – they don’t have to add up to the original estimate plus you have more information now to make a more accurate estimate.

You then agree as a team that for this sprint you’ll aim to get done the 13 point story, one 8 point story plus the 1 point url change you had already identified. So a total of 22 points. The next sprint you get 27 points done, the following sprint you get 18 points done. After 3 sprints you can start to get some confidence in your velocity (velocity is the amount of work your team can get done in one sprint). To get the velocity take the average of the previous sprints. So in this example the average is (22+27+18) / 3 = 22.3 so round it to the nearest on the Fibo scale which is 21.

Now for the next sprint just aim to get 21 points done.

Don’t get hung up on getting your story point estimate exactly right – it’s not an exact science. You know a url change is far less complex than aggregating data so just score it accordingly.

Plus discussing these things as a team is good. Look back at your estimates during sprint review and discuss if you were happy with them or not and then feed this into the next sprint planning session.

The whole team estimate

The whole team must agree on a single estimate for each story. A feature isn’t done until it’s production ready. Just getting the code written is by no means done. In my experience Scrum teams have been far more effective when working as a team. Take an example of the team I’m working with right now. When I joined they were doing all the sprint meetings and planning poker but during the sprint the process was 1. BAs/Product Owners define the requirements as stories with acceptance criteria and acceptance tests 2. They hand these requirements to the developer who then writes the code 3. The developer has the code merged into the development branch for QA to test 4. QA test then they start asking questions and tests fail so it goes back into development.

What’s missing here? There’s not enough discussion up front and each team member only saw their own task. Now the BA/PO, devs and QA get together before writing any code to discuss the requirements in detail and ask questions up front, then continue the discussion throughout the sprint. This is far more efficient and leads to better quality solutions.

Planning poker helps this process because it forces the team to discuss the feature and agree, as a team, how complex delivery of that feature is. In traditional software development the Project Manager was responsible for delivery of the project but anyone with experience of that approach knows it doesn’t work because more often than not, people do not take responsiblity for their part in the delivery of the application. In Agile you shouldn’t need project managers because the team takes responsibility as a whole for delivery of the application.

On time estimation of tasks

My view having worked with teams that estimate time on tasks and teams that only do story point esimtates is DON’T DO TIME ESTIMATES! They’re actually just a waste of time. They’re not as accurate as story points because they are specific to individuals not the team, and each individual will have a different idea of time estimation(bring on the flame).

Story points accept that things i.e. requirements, change all the time so really you need an indicator of what the team can complete in a sprint.

Once you have an understanding of velocity you can measure your deliverables in time because you know what you can get done in each sprint e.g. every two weeks you know what features can be delivered. Your scrum master and product owners should be having estimation sessions to look ahead to future sprints then you can get an indicator of how much work you’ll get done in the coming few months. This allows product owners to make prioritisation decisions about what features to include in the final application.

I’ve had developers ask that we estimate time for tasks in order to plan but I actually disagree with this approach (in fact I strongly disagree with this approach) because it is not accurate e.g. what does this will take me 4 hours really mean: one dev might include only the time on the task itself, someone else might add time for making cups of tea!

Time estimates are always handed to someone else for reporting purposes and it also overemphasises the individual elements of delivering a feature vs the whole team effort.

Estimation isn’t the biggest problem

As an aside, figuring out estimation is not the biggest problem I think teams have to solve. The most important thing is working together as a team to get things done throughout the sprint, so that you don’t hand everything over for testing on the last day. You want to see a steady trickle of features throughout the 2 week sprint. The team dynamic I explained above is a large part of this. Story point estimation will help you plan for this because you’ll see which are the big stories that need breaking down into smaller ones that can be delivered into testing regularly.

Wikipedia explains planning poker quite well. Let me recap some of what’s state there with a focus on your case:

Why planning poker?

First of all, you should all be on board as to why you are doing a planning poker as opposed to a “normal” estimation. The reason is actually quite simple: all of us suck big time when it comes to estimating time for a task. Pretty much every study has revealed, that the human brain is simply incapable of estimating task that take any reasonably amount of time. (Also a reason, why tickets that go beyond 2-3 days in their estimate are pretty much worthless in terms of their estimate.)

Why complexity rather than effort?

This goes hand in hand with the above. Effort usually means time, and we suck at that. Complexity instead is hard to quantify objectively, which is a good thing in this case. It’s your gut that tells you this story is going to be complex. For someone else it may be less complex. But you need not quantify exactly how complex it really is. You have no need to get this number X of complexity – as opposed to a timed effort, where you eventually have to agree that it takes X days or some such.

Why hide the cards?

The cards with your complexity guestimate are played hidden and then revealed all at once. This is done to ensure you are not influenced by other people’s opinions prior to making your own initial estimate. If everyone has about the same gut feeling in terms of complexity, then you’re done. If there are wildly different numbers occurring, you know there’s something to be discussed hidden there. In this way, you can very quickly deal with stories for which everyone has the same idea of the required complexity/effort.

Why Fibonacci numbers?

The numbers on your cards are typically Fibonacci numbers or some other kind of sequence with a lot of gaps in the numbers. This is to enforce you to fully trust your gut feeling. If you have to choose between 8 and 13, that’s much more of a statement than going for 9 or 10. Also, as mentioned above, the large differences are where the hidden problems are, so by enlarging the gaps, you increase the chance to detect these problems better.

Why does this work at all?

Interestingly, the first few times you do a planning poker it won’t work. It’s as simple as that. What does “3” or “5” even mean? There is no definition for what each number means (on purpose!) and it is up to your whole team to discover the actual meaning behind each of these numbers. Only after you have accepted estimating your stories in these numbers – and after you have realized several of these – do you get a better idea of when you should raise a 5 and when it is an 8 rather.

Once you combine this with the concept of velocity and measuring your sprint progresses via these story points, you have a whole new scale of efficiency that is more or less independent of traditional time estimations.

Nevertheless, for me personally, the most beneficial point of planning poker is that by using fibonacci numbers instead of time estimates, you have a much easier time to detect uncertainties. With classical time estimates you are not forced to make such “extreme” (due to the number gaps) decisions, hence, estimates may be rather close together and the team may falsely believe that they understood the story well enough.

Example

A simple example of what typically happens is that a story is presented, and then person A comes up with an objection. It’s something along the lines “please do not forget that this feature affects X and this may mean it’s more costly than what we thought so far”. The main problem is that there is always this person A at the table. There’s always something someone is worried about. If you have an open up-front discussion, you have no idea really how large of a worry this thing X is.

If you make hidden estimates based on time, then it gets a bit better. But still, a person A with a valid objection may not be a clear outlier in her estimate yet. On the other hand, with planning poker, person A has to think more about how much of an actual problem X is. For two different problems, you cannot properly distinguish their importance by the above “spoken text of objection”. Even with time estimates it’s rather hard to see which is more of a problem. The hope of using planning poker here is that you end up with one objection being just 2-3 points different from the others’ estimates, but the other objection which ended up 5 or 8 points away from the median may just be the most important uncertainty of your sprint planning.

After dozens of iterations in my team, we figured out that story points are mostly about medium-term project steering. They allow the product owner to project herself 2 or 3 sprints ahead and essentially make business and scope decisions about a release, based on an average velocity.

We’ve discovered that story points aren’t so much useful at a sprint level, because no 2 sprints are similar and predicting how much work will be done is impossible. Consequently, we decided we shouldn’t get obsessed with the estimation part and just take planning poker sessions as pretexts for conversation about features.

This concurs with a point made by Mike Cohn here.

As a side note, this is true for a given team, but there’s no rule about how story points will help you. I recommend you first stick to the methodology but try to quickly find out by yourself if and how they’re useful. Retrospectives will help you reflect on that.

The fundamental problem here is that it is broken. The PM wants to use planning poker to get an idea of the complexity of each story, with the intention of knowing roughly how many stories can be fitted into a sprint (the team’s velocity).

As a result, its a “not based on time” that is “based on time”. Its no wonder everyone gets confused.

There are ways to make this work for you. Firstly forget about effort and focus on complexity. Forget all about how long it might take to develop and focus instead on the areas each story affects. If you have a story that updates the DB, the server code, the client code and the client documentation, then you can say that’s a 4-point story. If it is only a change to the DB sql, then its a 1-point story. This gives you a more understandable way of figuring out relative complexity between stories. (You’ll have to come up with some metrics that make sense for your circumstances, maybe test coverage requirements or UI complexity)

My opinion generally though is that its a pointless waste of time that simply encourages sprint planning as if they were mini waterfall projects. Who really cares how many story points you can fit into a sprint? If you have left-over stories at the end of a sprint, you just do them in the next one. Given that, you might as well just make your backlog the size of every outstanding story you have and gradually whittle them all down over time. Delivery takes as long as it takes (but it’ll be quicker if you didn’t bother wasting 20% of your time in backlog and sprint planning meetings). At the end of the project, nobody cares how many story points were delivered. What people care about is the delivered project.

Also user story pointing gives the business a heads up in terms of if anything needs re-negotiating. if you have a month to complete some work you scored as 100 then you might be in trouble. it also gives you chance to break an epic story down into something smaller that still has value and can be completed in a sprint.