Content
The team compares the new work against work they’ve already done. They compare the complexity of the new assignment against past challenges and rank the difficulty as well as the time required. Scrum Planning Poker stepsBy hiding the figures in this way, the group can avoid the cognitive bias of anchoring, where the first number spoken aloud sets a precedent for subsequent estimates.
Often, one person is missing something or another person has specific knowledge that the others don’t. Exploratory studies by Nils Christian Haugen seem to confirm the value of the practices, which produces slightly better estimates than a single “expert’s”. The conversational format can uncover valuable insights from members of the team who might not otherwise have a forum to share their thoughts and experiences.
Estimation is a double-edged sword – it’s incredibly helpful to break long-term projects into manageable and short-term tasks, but a wrong move can derail long-term project planning. The core idea behind planning poker is to estimate items by playing numbered poker cards. To play planning poker, you’ll need a deck of cards for each person that has a sequence of values within it. Each person then uses their deck to vote on how long they think each task will take. Planning poker is based on a list of features to be delivered, several copies of a deck of cards, and optionally, an egg timer that can be used to limit time spent in discussion of each item. 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.
What Is Planning Poker And How Does It Work?
If team members are not clear on the how part of the user story, someone having a better understanding about it, explains it to the rest of the team members. In process if required, she may browse through the code-base as well to make things clearer. Story point sizing estimation in general is done through planning poker. There are also a number of “bad” pieces of advice that are repeated regularly.
Like other Agile methodologies, Crystal emphasizes frequent delivery of working software with high customer involvement, adaptability and the elimination of bureaucracy and distractions. Its key principles include communication, teamwork and simplicity. When participants disclose their estimates, they will have to back them up with reasoning on why they are high or low. This can open up questions on the requirement and implementation – a feedback loop that can detect the gaps. It can encourage newer employees to speak up by playing a card and explaining their logic. You and your colleague might give a smaller estimate, like 10 or 15.
When should we engage in Planning Poker?
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. The team of developers, together with the Product Owner, meets in a room, each provided with a physical card or a planning poker app. Or is it really huge like that one piece of work we finished last month? Doing relative estimates will not only reduce the amount of time spent on estimating work, it will also heavily increase the accuracy of the estimates.
You repeat the process with each task until you run out of them. Planning Poker makes team members break a project down into such small pieces that it becomes easier to assess the amount of time necessary to do each part. This process helps teams to plan out how much time they will need for the whole project. Teams should conduct a Poker tool session soon after creating the initial product backlog. Depending on the size of the entire project, the process can stretch into several days.
Priority poker is to help teams using the agile development methodology to reach a consensus on how long each task in a development cycle will take. Planning poker brings together stakeholders from across departments in the organization to reach a consensus on the estimated effort needed for several backlog initiatives. For an agile software organization, stakeholders can include a product owner, developers, UX designers, QA testers, and product managers, among others. Each individual lays a card face down representing their estimate for the story. Units used vary – they can be days duration, ideal days, t-shirt sizes or story points. During the discussion, estimations must not be mentioned at all in relation to feature size to avoid anchoring.
Some claim that estimates should only be given by those who are also working on the implementation of the task. If the Scrum Poker takes place in Sprint Planning, it is unclear who will take over which task later on in the implementation. Sometimes it is also advised to consider the higher estimate in case of uncertainty. In individual cases this may be correct, but it would certainly be better to reduce the uncertainty and define spike stories, for example. As soon as there is clarity about the actual scope of the task, nothing stands in the way of estimating the effort in a later Planning Poker. Finally, even if you can give an estimate it will probably be wrong the first time.
Step 3: Discuss
One engineer at the meeting, James Grenning, decided to get things back on track by suggesting a variation of the Wideband Delphi method. Some publications recommend limiting discussions to one minute, but this may be too short, as the focus is ultimately on agreeing on a common estimate. In fact, however, the use of maximum timeboxes – e.g. with 5 minutes – makes sense. Here, organisations should gather their own experience and make individual agreements. Each participant individually estimates the complexity of the task and places the card with the appropriate number face down on the table in front of him. A simple example of what typically happens is that a story is presented, and then person A comes up with an objection.
- Bugs, complications and feature changes either weren’t handled well, or were dealt with so late in the process that projects were seriously delayed or even scrapped.
- Units used vary – they can be days duration, ideal days or story points.
- Finally, even if you can give an estimate it will probably be wrong the first time.
- The higher a participant’s card is, the more difficult that participant estimates the story will be to complete.
- You can simply log in Scrum Master or Agile coach and a product owner’s account and set of items to be estimated.
- If you wish to collect the information about the work of planning poker with a distributed team, you must understand a simple concept in sequence ways.
When the team has thoroughly addressed the matter, each estimator discreetly chooses one card to represent their estimate. One pitfall of Planning Poker resides in making “convergence to consensus estimate” an obligation rather than a natural result of the conversation that follows a round of play. Doing so runs the risk of erasing useful information, i.e. the degree of uncertainty conveyed by a wide spread in the initial estimates. The Product Owner briefly states the intent and value of a story. Each member of the development team silently picks an estimate and readies the corresponding card, face down. When everyone has taken their pick, the cards are turned face up and the estimates are read aloud.
Planning Poker Definition
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 Agile you shouldn’t need project managers because the team takes responsibility as a whole for delivery of the application. Planning Poker is a consensus-based technique of gambling and estimation, also known as Scrum Poker, implemented within the agile teams, mainly within the scope of software development.
If all estimators selected the same value, that becomes the estimate. The high and low estimators should especially share their reasons. After further discussion, each estimator reselects an estimate card, and all cards are again revealed at the same time. The remaining stories will likely not fit within the sprint planning timeframe. These stories are in pile two, which represents the sprint backlog.
Apart from these changes in code, the team may need to do some testing around it. In order to compare the amount of work of one story to another, we need to identify a base story in definition of planning poker order to define the base story point size. One of the most appealing aspects of Priority Poker / Planning Poker is that it can be carried out with minimal effort and resources.
How to play Priority Poker / Planning Poker
Teams can play Priority Poker with a simple set of blank cards, on which you write numbers representing the effort a task might require. Players pick a card anonymously and the team discusses the outcome. Each member of the team will choose a card from their deck — one that they feel represents the amount of effort required to complete this task. Even introverted participants can have their say (unless they consciously try to avoid discussions by estimating effort with apparent mean values. If in doubt, the moderator would be called upon here). Also user story pointing gives the business a heads up in terms of if anything needs re-negotiating.
Tools
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. These numbers can also be fed back into your tracking tool to help better predict how long stories will take. As with time estimates containing hidden pressures, so a measure of effort also has issues.
In this way, you can very quickly deal with stories for which everyone has the same idea of the required complexity/effort. 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 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. https://globalcloudteam.com/ 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. For example, teams can use ScrumPoker – a Microsoft Teams add-on that enables them to work faster and get more effective estimations of stories.
The Product Owner presents to the team a user story and provides a space for questions so that all the people understand it. They can start from the same base in order to make an estimate of each of the items that make it up. FFD begins by defining an overall model shape, which in turn creates a feature list. The method then proceeds with iterations that last two weeks and focus on planning by feature, designing by feature and building by feature. If a feature takes more than two weeks to build, then it should be broken down into smaller features. The primary advantage of FDD is that it isscalable– even to large teams — since it uses the concept of “just enough design initially,” or JEDI.
This post is part of a blog post series on story points and agile estimation. To read rest of the posts on the subject, please navigate to All About Story Points and Agile Estimation Series. This way the card gets sized to a story point and the team moves to the next card. If everyone has the same number, that becomes the size of the card. Otherwise, the facilitator asks the team-members with the highest and the lowest numbers to explain their reasons on why they have high and low numbers. That additional field may in turn require some changes in the existing UI, some changes in an existing Service to get that field from a database, and a DAO may already have that field with it.
Read all you have to know about an efficient project meeting. Automate the Scrum events and related activities with self-explanatory instructions, samples and required document templates. Our brain is not capable of doing absolute estimates; we always put that new thing that we need to estimate in relationship to things we already know. The Golden Hammer antipattern can sneak up on a development team, but there are ways to spot it.
