Many people have used a variation of Planning Poker to do Agile estimation. Here is a reference of 9 different Agile estimation techniques for different circumstances. I have seen all of these techniques work in practice, except one. Try a new one each Sprint!
Participants use specially-numbered playing cards to vote for an estimate of an item. Voting repeats with discussion until all votes are unanimous. There are lots of minor variations on Planning Poker. Good technique to estimate a very small number of items (2 to 10).
The Bucket System
Using the same sequence as Planning Poker, a group or a team estimate items by placing them in “buckets”. The Bucket System is a much faster Agile estimation technique than Planning Poker because there is a “divide-and-conquer” phase. The Bucket System can also be used with larger groups than Planning Poker and with very large numbers of items to be estimated (50 to 500).
For super-fast Agile estimation, the items to be estimated are simply placed by the group in one of three categories: big, uncertain and small. The group starts by discussing a few together, and then, like the Bucket System, uses divide-and-conquer to go through the rest of the items.
TFB / NFC / 1 (Sprint)
This Agile estimation technique is similar to Big/Uncertain/Small but puts a specific “size” into the mix, namely 1 Sprint. The categories are “Too F-ing Big”, “No F-ing Clue” and “1” Sprint (or less). I learned this one recently from someone in one of my CSPO classes.
Dot voting is usually considered a decision-making tool, not an Agile estimation technique. However, for estimating small numbers of items, dot voting can be a super-simple and effective technique. Each person gets a small number of “dots” and uses them as votes to indicate the size of an item; more dots means bigger.
Items are categorized into t-shirt sizes: XS, S, M, L, XL. The sizes can, if needed, be given numerical values after the estimation is done. This is a very informal technique, and can be used quickly with a large number of items. Usually, the decisions about the size are based on open, collaborative discussion, possibly with the occasional vote to break a stalemate. There is a brief description of T-Shirt Sizes here.
Items are grouped by similarity – where similarity is some dimension that needs to be estimated. This is usually a very physical activity and requires a relatively small number of items (20 to 50 is a pretty good range). The groupings are then associated with numerical estimates if desired.
Items are placed in a random order on a scale labeled simply “low” to “high”. Each person participating takes turns making a “move”. A move involves one of the following actions: change the position of an item by one spot lower or one spot higher, talking about an item, or passing. If everyone passes, the ordering is done. The Challenge, Estimate, Override and the Relative Mass Valuation methods are variations on the ordering protocol.
Divide until Maximum Size or Less
The group decides on a maximum size for items (e.g. 1 person-day of effort). Each item is discussed to determine if it is already that size or less. If the item is larger than the maximum size, then the group breaks the item into sub-items and repeats the process with the sub-items. This continues until all items are in the allowed size range.
Principles of Agile Estimation
Agile estimation techniques are collaborative. All appropriate people are included in the process. For example the whole Scrum team participates in estimating effort of Product Backlog Items. Collaborative techniques are also designed so that it is impossible to blame someone for an incorrect estimate: there is no way to trace who estimated what.
Agile estimation techniques are designed to be fast (-er than traditional techniques) and deliberately trade off accuracy. We are not trying to learn to predict the future… or get better at estimation. Instead, we recognize that estimation is a non-value added activity and minimize it as much as possible.
Most Agile estimation techniques use relative units. This means that we don’t try to estimate dollars or days directly. Instead, we use “points” or even qualitative labels and simply compare the items we are estimating to each other. This takes advantage of the human capacity to compare things to each other and avoids our difficulty in comparing something to an abstract concept (such as dollars or days).
Agile methods such as Scrum, Kanban and OpenAgile do not require long-term up-front plans. However, many teams desire a long-term plan. This can be thought of as a roadmap or schedule or a release plan. Agile planning helps us build and maintain long-term plans.
Agile Planning Process
The steps to do this are actually very simple:
Write down all the work to be done. In Scrum these are called “Product Backlog Items”, in Kanban “Tasks” and in OpenAgile “Value Drivers”.
Do some estimation of the work items. Many Agile estimation techniques exist including Planning Poker, The Bucket System, Dot Voting, T-Shirt Sizes. These tools can be applied to many types of estimation. There are three kinds of estimation that are important for Agile Planning:
Estimating relative business value. Usually done with the business people including customers and users.
Estimating relative effort. Usually done by the Agile team that will deliver the work.
Estimating team capacity. Also done by the Agile team (this is sometimes called “velocity”).
Create the long-term plan. Use the team capacity estimate and the sum of all the effort estimates to come up with an estimate of the overall time required to do the work. (In Kanban, which doesn’t have an iterative approach, this is a bit more complicated.) Use the business value and effort estimates to determine relative return on investment as a way to put work items in a logical sequence.
Agile planning allows a team to update estimates at any time. Therefore, the techniques used above should not be thought of as a strict sequence. Instead, as the team and the business people learn, the estimates and long-term plan can be easily updated. Scrum refers to this ongoing process at “Product Backlog Refinement”.
Principles of Agile Planning
In order to use Agile planning effectively, people must be aware of and support the principles of Agile planning:
Speed over accuracy. We don’t want to waste time on planning! Planning in and of itself does not deliver value. Instead, get planning done fast and use the actual delivery of your Agile team to adjust plans as you go.
Collaborative techniques. We don’t want to be able to blame individuals if something goes wrong. Instead, we create safe estimation and planning techniques. Inevitably, when an estimate turns out to be wrong, it is impossible to blame a single individual for a “mistake”.
Relative units. We don’t try to estimate and plan based on “real” units such as dollars or hours. Instead, we use ordering, relative estimation and other relative techniques to compare between options. Humans are bad at estimating in absolute units. We are much better at relative estimation and planning.
You probably already use an Agile Estimation technique such as the Planning Game or the Bucket System, but surprisingly few people understand the underlying principles of Agile Estimation. This lack of understanding often causes confusion or stress for the people who try to use Agile Estimation techniques. The discrepancy between traditional estimation techniques and Agile techniques is large and it is hard to bridge that mental gap without understanding the principles involved. There are three fundamental principles of Agile estimation:
Principle One: Collaborative
Agile estimation methods are collaborative. This means that multiple people work together to arrive at estimates for work in an Agile project or product development effort. Traditional estimation techniques (such as those related to bottom-up or top-down) tend to focus on individuals estimating the work that they are responsible for doing and “trusting” those individual estimates. Collaborative estimation means that most estimation is done by people in formally facilitated meetings where people are present in-person.
Collaborative techniques are generally used where there is some expectation that multiple minds are better than a single mind in discovering some new knowledge or solving a problem. Teamwork and groupwork are based on this concept. This idea of collaboration for problem solving is also applied to Agile Estimation and it has some interesting ramifications.
The most radical consequence of collaborative estimation methods is that there is no possibility to trace a particular estimate for a particular item to a particular individual person. This lack of traceability is important to create a sense of safety on the part of participants in the estimation effort. This safety is necessary to allow participants to be fully honest about estimates even if those estimates conflict with expectations of powerful stakeholders. Another way of stating this principle is that no individual can be punished for a bad estimate.
Many Agile estimation techniques take this principle beyond just mere collaboration to the level of consensus-building techniques where everyone in a group doing estimation work must agree on the final estimate for each and every item being estimated. This strengthens the idea of safety to the point where no participant in an estimation effort can ever say “I didn’t agree with that” and thereby leave other participants “on the hook” for a bad estimate.
Principle Two: Relative Estimation
Imagine you are shown a glass bottle with some water in it. You can see the water sloshing around. Someone asks you, “how much water is in the bottle?” You might, at first, think about the overall size of the bottle and respond by saying “it’s 1/3 full.” Or, if asked to provide a measure in units like millilitres or fluid ounces, you might mentally compare what you see in front of you to some container (e.g. a measuring cup) where you know the quantity. In both cases, you are doing a relative estimate of the amount of water in the bottle. You are comparing the amount of water to a known quantity.
Imagine a counter-example: someone walks up to you with a red pen ask asks you “what is the wavelength of the light being reflected from this red ink?” If you are like most people, you have probably forgotten (if you ever knew) the wavelengths of light in the visible spectrum. You have no basis for comparison. You might take a wild guess, but it is just that. Going back to our relative measure, you might be able to easily say if it is darker or lighter than another red colour, or you might even be able to tell what hue of red it is. But those cases are, again, relying on our inherent ability to see relative differences.
So instead of ignoring this capacity, in Agile estimation techniques, we leverage it. When estimating effort, we start by setting a clear baseline for what we are comparing: another piece of work. The baseline piece of work is often given an “estimate” that is arbitrary and in some non-standard units. For example, it is common to use “points” when estimating the effort for Product Backlog Items.
When doing relative estimates it is very important to ensure we are comparing “apples to apples”. Both the piece of work to be estimated and the comparison piece should both be work items that are not yet done! If you have already completed one of the pieces of work, you have prior knowledge that you don’t have for the work to be estimated.
This last point is subtle, but important. If you have already done something, you know much more about it. If you try to compare to something you haven’t yet done, you will be tempted to assume that the two things will be more similar than they may be when you actually get to work on it. By comparing two pieces of work that you have not yet done, you become much more conscious of the risks of comparing, and that consciousness will help you make better relative estimates.
It is important to note that one side advantage of using relative units for estimation is that it makes it much more difficult to use estimates as a baseline for either measuring performance or for tracking schedule variance, both of which are essentially meaningless in a good Agile environment (which should be almost entirely results-oriented).
Principle Three: Fast
In Agile estimation we don’t care (!!!)about accuracy nor about precision of estimates. Whoa! Why is that? Because estimation is waste. You can’t sell estimates, and estimates don’t affect the “form, fit or function” of the thing you’re building. Therefore, both Agile and Lean concur: do your utmost to eliminate that waste. There are actually lots of Agile practitioners who think estimates are evil (and they have some good arguments!)
In order to do Agile estimation in a maximally non-evil way, we need to make estimation fast! Really fast!!! Many of the Agile estimation techniques allow you to estimate a product release schedule lasting as much as a year in just a few hours given a reasonably well-crafted Product Backlog.
There are really only two modestly good reasons for doing estimation in an Agile project or product:
Estimates provide simplified information to the Product Owner to allow him/her to make sure the Product Backlog is ready for the next Sprint (ordered, refined).
Estimates allow stakeholders, including the team doing the work, to generate high-level common understanding and expectations without dwelling on details.
As a business stakeholder, one can do a simple mental exercise. Ask yourself, “how much money would I be willing to spend to accomplish those two objectives?” Whatever your answer, I hope that it is a very small amount compared to what you are willing to spend on getting results. If not, perhaps you haven’t really embraced the Agile mindset yet where “the primary measure of progress is working software” (the Agile Manifesto).
Bonus Principle: We Suck at Estimating
Most people doing estimation in traditional project management try to measure in units like person-days or dollars. There is no doubt that these units are useful if you can get good estimates. However, most of the people doing estimation are fundamentally and irredeemably bad at it. How do I know? Because they are not wealthy… and have thereby proven that they cannot predict the future. If you can predict the future, even just in limited circumstances (like estimating effort or revenue), you can leverage that to generate almost untold wealth. Given that, it is fruitless and wasteful to try to get better at estimating. Instead, the principles of Agile estimation help us focus our attention on the right things: collaboration, comparative estimates and doing them fast so we can get to the real work, and most importantly: delivering valuable results now. Understanding these principles helps teams overcome many of the struggles they have in using Agile estimation techniques.
I’ve made a minor update to my article about Agile Estimation with the Planning Game to include a downloadable pdf of the article for easy printing. The downloadable version also includes a tiny bit of commentary that comes from my upcoming Agile Advice book. There are also two links added at the end of the article. One is the the wikipedia article about Planning Poker (which describes the method slightly differently), and the other is to an article I wrote a long time ago about the wideband delphi estimation method.
For many of you, there will be instances where Scrum or Agile is something a company is trying but does not really buy into or understand yet. I would like to start by saying. There is hope!
The following story is about implementing Planning Poker in Priority Meetings at the senior management level using the OpenAgile’s Open Learning System. Perhaps it could help you introduce Agile to different parts of your organization.
For those types of companies, Agile Development processes can be introduced and progress made with very little effort on your part. You won’t get the full benefit, but at least people will get to know Agile as a great way of making real progress in an organization.
Consider the following situation…. You work for a company that has “heard” of Agile and is allowing you to implement whatever you can in regards to Agile for the Development Team “as long as it doesn’t affect other parts of the company too much”.
If you’re like me, you’ve likely heard this more than a few times.
I recently had an opportunity to find a new way to introduce Agile Processes to senior managers who are not really familiar with the processes and also are not willing to put the time in to learn them.
I’d like to pass on an idea about how you could possibly make some small headway in regards to Planning.
Imagine you are working at a company where there are several owners or stakeholders responsible for the future “work backlog” of features for your environment.
Generally, when planning sessions take place, it involves an aggressive battle over who will get what feature first, what is more important (systems, back-end, front end, graphics, this enhancement, that enhancement).. You all know the drill.
I had many such meetings with the stakeholders of a company where I had the opportunity to introduce Planning Poker Cards to these meetings with great success.
About once every 1 or 2 months, a “priorities meeting” was scheduled for a Wednesday afternoon. After successfully implementing Agile process for the development team, it was time to help the rest of the company out.
I prepared by doing a few things;
– Prepared pictures of existing Scrum Rooms to show how developers and planning boards would eventually look (thanks to Mishkin Berteig of Berteig Consulting for providing additional examples).
Of course, I made sure of standard things such as making sure the PowerPoint will work on the equipment in the meeting room. When it came time for the presentation, I knew it would work. It’s hard to show how productive your processes are if you can’t get yourself properly organized.
-I made sure I had a deck of Planning Poker Cards available.
-I explained to the Stakeholders that I would like to do something to “take the emotion out” of the planning process and make sure everyone’s opinion is heard and valued. I explained how this process was intended to make the planning a very business-like process, and a way for us to quickly get through what was generally a long, several meeting process in one easy step.
-I asked them to trust me (which remarkably goes a long way), and said, “I would like to show you this to try and move the meeting along, take out the emotion and have us end up with the best ROI (Return on Investment) in future. I asked if they would agree to give it a try.
At first, there was little interest in learning or seeing the processes because of course anything about “Agile Stuff…has nothing to do with Senior Management”, so it was all a matter of “Let’s get down to it” as to not waste time.
I took about 20 items from the queue and converted them to Index Cards and put them on the table.
I asked them to find the least valuable item to get done (there are literally hundreds of backlogged items). This alone seemed like it might take a considerable amount of time, so I decided to take a slightly different approach.
I waited for an index card that I knew I could get agreement on as being of fairly low value and had my starting point. There may have been lower items, but this could safely be agreed upon by everyone as a low priority or low value item. This process works well as it’s usually easier for people to agree on what’s not important or valuable. I’m not sure why… But hey, it works!
It took only a few cards and although the process was not in “strict adherence” to the no negotiation and no showing your cards rules, in this case it was VERY effective.
The owners of the company prioritized BY VALUE several hundred feature requests in just over 2 hours. I think it’s astounding that by just letting them make up their own system with what I introduced to them, they also were able to self-organize, agree on a different approach, and be successful with their own way of doing things. All I needed to do was introduce them to the tools.
A few times during the cycle, I needed to re-affirm the process was about VALUE only and not about how long these would take. This seemed to be a large stumbling block at first, but eventually it was accepted. I explained that the development team would be the estimated (Investment) part later. We would divide their value (return) / by the developers estimates (investment) and the system would work itself out by providing a general Return on Investment Calculation.
They asked me about what would happen with all the cards… And, now the opportunity to show pictures of Scrum Rooms or Agile Rooms presented itself.
The managers were very happy with idea that they could “adjust priorities” many releases in advance. This for them, was a big bonus. I explained that once we have big boards with all the User Stories on them, it would benefit everyone.
– Everyone in the company could go to the board and see what features were going to be coming soon. This turned out to be extremely motivating for the Sales People. The idea of knowing what at least was being Planned was exciting to them. Of course, I explained to them and the sales manager that there were no guarantees of what would get done if at all, but at least they would know if any of their specific requests were even in the pipeline at all.
– The senior management have always been wondering how the Development Team was doing. This was the ideal solution. A big giant board that everyone can understand at a glance easily solves this. Such a simple technique and yet so powerful!
– An idea how the current release is going. As Scrum or OpenAgile practitioners, we all know the value of this type of information is amazing. To know how far in the cycle you are based on simply looking at the Board is so simple.
– In the past, the development team generally knew what was coming up only 1 or 2 releases before it was time to do the work. Knowing what’s coming down the pipe avoids potential code conflicts, systems conflicts, marketing conflicts, and generally keeps everyone motivated and excited about the future.
– An un-expected side effect which I was not expecting was that there was a developer who was worried about future work. Seeing hundreds of cards in the queue of work solved that problem. As we all know, lists of future work can usually be never ending :->
Teams can then start estimating the Work portion using the same system. What you end up with is ROI (value over investment) for your queued up work. The company may not live with it, but it gives a simple starting place for everyone to discuss openly.
Another real benefit is that the emotional roller coaster of settings priorities is much less a factor with this type of process. Everyone has agreed as a team to the Value and everyone has agreed as a team to the Estimates, so there’s really nothing other than pure politics to stop the plan from working now.
I was pleased that at the end of the first attempt at doing this, there was an overwhelmingly positive response.
There were a few surprises. For instance, one of the managers wanted to be in the Estimating meeting with the developers to Ensure we “get the right answers”. However, I needed to stand firm. Again, I asked them to trust me and simply said “No, it won’t work that way, sorry… I DO promise, though that if there is something we don’t understand, we’ll consult you.”… The Stakeholder was happy with that.
In reality, all that manager was worried about was that we might consider one of their tasks less important or overestimate the intention and therefore overestimate the time it would take to complete, and therefore, lower the ROI on it. That owner wanted to ensure that a very specific high priority project got put into the queue.
It is after all their company. We all need to remember that owners need to have some rights as well <grin>.
In my case, I know that what might happen is that one or some of the items may end up overstepping the process due to factors outside the teams’ control.
This is a reality of working in a smaller development environment… actually… in reality, many environments.
However, I still consider this a major breakthrough for several reasons.
1 – Even if a few items bypassed the process at least the several hundred other features and tasks did not. Who can complain about that!
2 – The owners were now in the “frame of mind” that tasks can be easily be classified as to value.
At first it was difficult for them to specify value for large features because they believed they might be huge projects and they didn’t want to send the team on a huge development task and risk losing other important features that were already in the queue.
I explained to them to not worry about this as the ROI formula will actually make these projects less of an ROI at THIS time. As they want to move the bigger cards closer to the upcoming release, we will break them into smaller pieces in the same fashion and eventually those parts of the system would be worked on as the smaller parts would have potentially higher ROI’s.
This of course, made sense to them. The key here is that huge tasks should be split into smaller tasks as they get moved on the Planning Board, Information Radiator or whatever you want to call it. As items move closer to the release cycle, their value should naturally be increasing as well. Then, upcoming features can be re-sequenced and prepared to get injected into the development process using another planning cycle.
All the time, it’s about Value for Work performed….. This is of course what being in business is all about.
Some values are about taking care of long-term customers, some are purely political and some are just about making sure the system doesn’t crash. Value is about the overall impact to the health of the organization.
Planning cards make this a non-emotional event.
I knew the system was working because a funny thing happened. Several days after the first planning cycle, I received notification of new Feature Requests from clients and our support department with some unusual coding on it.
“The ABC type of customers are looking for this feature in the product; It’s something we really should consider doing soon… We’ve talked about it and think it should be at card level 8 or 13”.
This to me was a great thing to see!
For those of you who don’t know; Scrum or OpenAgile Planning Poker cards are purposely set up to have a non-uniform number sequence to avoid mathematical calculations and exact figures. They are about relative value to other each other and not fixed numbers.
The key is to keep it simple and remind everyone using the cards that this is not intended to be a perfect estimation. This is a relative estimation of value or work.
The fact that the stakeholders had started using this terminology showed that they not only understand that process but truly see its’ value.
One complaint from the past had always been that everything has been either High Priority, Medium Priority or Low Priority. Planning Poker Cards have helped them to take the emotion out of the Priority process and ultimately give them Many Levels of Value Priority in a simple way.
Perhaps planning poker might help in your environment to help set priorities, not just for development but for any set of complicated project.
Many of us think of Planning Poker as a developer only thing, but as you can see from this story it can be used as an effective tool for any process. Give it a try and you might just be surprised at how stress-free of a process it can really be for your priority meetings.
The read about the specifics of Agile Planning Poker, try Wikipedia.
To find out more about OpenAgile and its’ flexibilities regarding release, or cycle planning, go to http://www.openagile.com.