Create a room and invite your team with one click — no signup, no email.
Set-up in seconds. Use the instant room feature or sign-up to keep the same room number for future plannings - making the set-up even faster.
Invite your colleagues to your planning poker by sharing the room id, let them scan the QR code with their mobile or just send them the link. If you have trouble to find a common timeslot, create a poll with our Doodle alternative "Whocan.org".
Once your team has entered the room, you can see them online and the scrum poker can start. The team can submit estimates, see who has provided estimates and show the results.
Everyone who has worked with Scrum, SAFE or other agile methodologies that rely on story-point estimations to judge the complexity of a feature knows how tricky these planning poker sessions can be. At the same time everyone is painfully aware how crucial a good planning session is on one hand to make sure that the agile team agree on the acceptance criteria, the definition of done and overall scope and on the other hand to allow the product owner to make an informed decision when prioritizing the backlog.
So how exactly do you make a scrum poker session successful? To understand the recipe for successful planning we will look at what a well prepared user story is, how to present it, some best practices for the poker itself and how to deal with discrepancies between estimates.
This might be a straight-forward advice but to have a successful estimation session, it is important that the feature or user story that we want to estimate is ready. So how do we get a story ready? In Scrum this is generally done during the refinement sessions, where the product owner together with the development (and often under the guidance of a scrum master) discuss the details of the story.
In our team, this starts with the product owner presenting in a succinct manner, what the user wants to be able to do and what value for him is. This second part is especially important as it should give a sense why what we are doing matters. The most widespread structure for a user story is "As a …, I want to do …, so that …".
Often the product owner will also have written down some high-level acceptance criteria, that are then discussed with the development team. Maybe counterintuitively, good acceptance criteria are high-level conditions that would satisfy the customer and allow them to achieve the value defined and not finely detailed requirement description of the solution. Together the scrum team discusses the the user story looking at the acceptance criteria and might decide to add or remove some of them or clarifying elements that are clearly out of scope.
Once everyone agrees on the acceptance criteria and the definition of done, we can move on to the actual estimation using in our case the Scrum Poker (also called Planning Poker).
This is the moment where the estimation tool on scrumpoker-online.org becomes helpful. We recommend opening the session at the beginning of the refinement or planning session and have all members of the scrum team enter the room using the room ID provided. Once the user story has been discussed and all question answered all the members of the development team start estimating the complexity of the story by giving it story points. Ok, story points and complexity, you make that sound easy… but what exactly are story points and how do I know how many story points should be assigned to a story?
Story points in scrum are an abstract measure to represent the complexity of implementing a user story. In general this "complexity" is related of course to effort, but also to risk and difficulties foreseen. The measure is abstract, because it cannot be related to a unit of time such as person days or hours.
Scrumpoker-online.org uses the fibonacci sequence (1,2,3,5,8,13,21) to estimate stories. It is also very helpful to have a reference user story that all the members of the scrum team have a good understanding of and assign it an estimate. The team can then start estimating other user stories by comparing them to the reference user story. So for example if the reference user story was estimated at 3 points, a story that has only 1 point should be three times less complex. As such the absolute value of the stories are less important than their relation to each other. And remember to stay agile and start experimenting, the more stories the team estimates the better they will get at it.
After everyone has turned in their estimates, the product owner or scrum master shows the results and if they all match, the story has been successfully estimated. If on the other hand there are some discrepancies, the members that are the furthest apart can start discussing why their estimates diverge. Most often this is an indication that there is not yet a common understanding of everything that this story entails. This discussion can lead to redefining the acceptance criteria and this is absolutely normal, this is afterall an iterative process.
A well estimated story helps greatly for the product owner to better judge if the value of a user story (or new functionality) is worth the complexity and effort to implement it. Furthermore it allows to get a better grasp on planning a sprint: after the first sprint, the team will know exactly how many story points they were able to achieve, thus the following sprint should be filled with a similar sum of story points. As the team gains knowledge and becomes more efficient, delivery of an amount of story points could be achieved faster than previously. But this is the second step – for now start estimating during your planning poker session using scrumpoker-online.org and enjoy the pleasure of trying to agree on an estimate… You will see, it will do wonders for producing a shared understanding of what is expected.
What agile story points actually measure, why they are not hours, how to run a story-pointing session, and how story point estimation works with Jira — including a cheat sheet.
Read more →An honest comparison of the most-used online planning poker tools — PlanningPokerOnline, PlanITPoker, PointingPoker, Parabol, and Scrum Poker Online. Pros, cons, and which one fits your team.
Read more →Jira does not include planning poker out of the box, and the available plugins are paid add-ons. Here is how to run planning poker for a Jira-driven team without the plugin — using Scrum Poker Online in a browser tab.
Read more →