Scrum Planning Poker Story Points
Story Points 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. Story points and velocity are probably the most well known tools for estimation in Agile environments. They are the basis for predictability with Scrum. To begin with, we should be clear on what a story point is. Most people reading this will have heard at least one definition, and probably more than one. Scrum Poker can be used with story points, ideal days, or any other estimating unit. Planning Poker in Scrum brings together multiple expert opinions for the agile estimation of a project. Story Point - Scrum poker (also called planning poker) is a fast and easy way to make estimates needed to reach a goal. Just pick a value that fits your needs for that goal, tap it and see what the.
- Scrum Story Points Definition
- Scrum Planning Poker Story Points Template
- Scrum Story Point Cards
- Scrum Planning Poker App
- Scrum Planning Poker
- Scrum Planning Poker Guidelines
What is it?
Story Point is an arbitrary unit of measurement to measure amount of work in a Sprint. It’s a pretty abstract concept and can be very hard for people to comprehend. Is it same as hours? No. Similar then? May be.
What is it then? It is something that you can relate to Sprint to Sprint. If your team accomplished x story points in one Sprint, given the same amount of resources and time, team should be able to accomplish more or less the same next Sprints. Once you do it a couple of times, you should be able to get your team Velocity.
Other Industries
If you take a look into Construction or Manufacturing industry, the measurements are pretty accurate and pretty standard. Everybody know what an 1 mm drill is (if there such a thing :)). You go to Home Depot, every part has measurable characteristics: height, weight, width, color, etc. Why shouldn’t your Scrum Team be: Resources, Duration, Sprint Goal, Story Points, and Velocity.
Story Points are usually based a mathematical number series called as Fibonacci Sequence.
Fibonacci Sequence
Wikipedia has a good read on what they are. It essentially are numbers as 1, 2, 3, 5, 8, 13, 20. Note number on right is addition of last two numbers on left 8 = 3 + 5, 13 = 5 + 8.
Each PBI (Product Backlog Item) is supposed to have Story Points associated. This is done by a voting process (sounds funny, but it’s important). Only Pigs (Team members responsible for building the feature Dev, QA, UI/UX, Doc) are allowed to vote.
Voting is also referred as Planning Poker. Why Poker: Because Pigs don’t know what other Pigs have selected unless “Show” is called by.
Voting (Planning Poker)
During the Sprint Planning meet, the Product Owner spends about a minute explaining the PBI that needs to be have Story Points assigned. In the next minute or two Pigs ask questions to get clarity. Note: This is not a feature discussion meeting. Pigs and Product Owner should have a good idea about the PBIs prior to the meet. What you are trying to do is assign Story Points, so you can predict future Velocity.
Each Pig is handed over a deck of cards. There are seven cards in the deck with each containing one of these numbers: 1, 2, 3, 5, 8, 13 and 20. When asked to vote, each Pig should individually select a card and put it on the table face down. When asked to show, everyone should show their cards together. People on the phone are asked to tell first so they don’t get influenced by the outcome of physical cards.
Story Point Guidelines
This is the most important aspect of allocating Story Points. Every team member must know how to pick one of those Fibonacci numbers. It might be a bit easier if you think from an elimination point of view.
20 – Too big for the Sprint. You need to break the PBI into smaller PBIs. Ideally nobody should have selected this number in voting. If they have then be prepared to talk about it.
13 – Something that will take full Sprint to accomplish. You should also be very clear what exactly does done mean for the PBI. Is it just Code Complete, or does it include QA and Documentation. Ideally PBIs should be created in such a way that the Product becomes releasable at the end of Sprint. However, this may not be very practical. I’ll table that discussions for a future Blog. For now keep in mind that you need to assign 13 if you think this will be going on through out during the Sprint by 1 person. In a 15 day Sprint: 8 days for Dev, 4 days for QA, 1 day for Doc.
8 – Something that takes half the Sprint.
5 – 5 days (in a 3 week Sprint)
Scrum Story Points Definition
3 – 3 days (in a 3 week Sprint)
2 – 2 days
1 – 1 day or less
less than 0 – Combine such PBIs into 1 or more
Again, your definition may differ depending on duration of the Sprint. The above is based on a 3 week Sprint. With lots of experimentation we’ve concluded that 3 weeks Sprint is the best. Perhaps another blog to talk about that.
What you really need is a framework to which your team members can associate these numbers to. A 5 may be 3 days in your company.
During the first few Sprint your team members may be asking questions as: What does 3 mean again? and 5..hmmm.. how about 13. I don’t have card for 10? That’s perfectly normal to ask.
Scrum Planning Poker Story Points Template
Re-Voting
It’s unlikely that everyone will come to the same number on the very first voting. It may be possible that majority come with same numbers with a few on the extremes.
People voted on the extremes should be asked to explain their rationale. After listening to arguments and arguments team should vote again. Move on to the next PBI as soon as you hit a consensus. Again it’s not necessary that everyone has the same number. In the interest of keep moving in the meeting you may pick the number with majority of the votes and continue on to next PBI. With time you’ll get better with all this.
IMO you should not go beyond two rounds of voting (including the first round) for a PBI. If you need multiple rounds then there is a bigger problem. People should have a good understanding of the PBI prior to coming to the Sprint Planning meeting. Focus on solving that problem first.
Total Story Points
At the end of the Sprint Planning meet you should total all the Story Points of individual PBIs and find out what the total is. This total is very important. Total will dictate your Velocity. If you did x this Sprint, you should be able x next Sprint and so on.
Still not convinced
Well, you are not alone, I struggled for a long time. All I can say is keep practicing and you will get it.
Story points and velocity are probably the most well known tools for estimation in Agile environments. They are the basis for predictability with Scrum. To begin with, we should be clear on what a story point is. Most people reading this will have heard at least one definition, and probably more than one. I’m going to go with the king of planning poker, Mike Cohn.
Mike defines story points in the following way :
“They are a unit of measure for expressing the overall size of a user story or feature. They tell us how big a story is, relative to others, either in terms of size or complexity”
With that understanding, let’s set the scene. We are in our sprint planning meeting. The Development Team (DT) are sat alongside the Product Owner (PO) who has bought along their prioritised product backlog, and the Scrum Master (SM) is about to kick the session off by defining the desired outcome of the meeting. The desired outcome of the sprint planning meeting may be as follows:
- There is an agreed sprint backlog
- The DT have reached a consensus on the size and complexity of each story in the sprint backlog (in story points)
- The DT and the PO have a shared understanding of each story in the sprint backlog
- The SM has ensured that the team have not planned too much work by checking the story points planned against a known velocity
As the session goes on, the product owner will talk through each story on the the product backlog. The team will ask questions of the PO and of each other in order to gain a shared understanding of the story. Once they think they have this, the SM will provide them with planning poker cards and the act of sizing will begin.
Scrum Story Point Cards
The DT will be a group made up of people with different levels of experience, knowledge and skill. Sizing with planning poker helps to ensure that everyone’s voice is heard, and that all opinions are taken into account, not just those of the team lead or architect. In this way it may be possible for anyone in the DT to pick up any story during the sprint.
To begin, the DT find a benchmark to relatively size each new story against. In sprint one, the SM may ask them to find an average size story on the product backlog. In later sprints, perhaps more appropriately, they may look back at stories already completed and find one with a size they now know to be accurate.
The SM will ask the DT to decide individually the size of the story being discussed, and the DT will hold up the card representing that number of story points. They will do so simultaneously so as not to be influenced by any other member of the team. If the DT don’t have consensus on the size of the story, further important discussion will ensue, facilitated by the SM. It may require another round or two of poker, but eventually consensus will be reached on size as members of the DT persuade each other with constructive reasoning.
This process will be repeated with the next story on the product backlog, and then the next, and so on until the DT believe they have enough work to fill the sprint. Now the SM will check to see how many story points have been planned. If this is the first sprint the DT have undertaken they will probably agree to start with what they have. If not, the SM will compare the number of points planned against team velocity.
Scrum Planning Poker App
What is our team velocity?
Velocity = total story points / no. of sprints
For example
Last 5 sprints completed points were:
30, 40, 50, 60, 70 = 250 points / 5 sprints = velocity of 50 points
Now that we have our velocity, we may want to turn that into a time estimate.
How big is my project?
Total estimate (points) / velocity = number of sprints
e.g. 500 story points for project / 50 points = 10 sprints
How long will it take?
Number of sprints x length of sprint (weeks)
e.g. 2 weeks sprints = 10 sprints x 2 weeks = 20 weeks
Scrum Planning Poker
Of course, this still requires you to have broken down the entire project into stories and to have sized all of them. This is a significant up front task.
The alternative is to try and keep projects relatively small, and to plan at a number of different levels. At a project level, use ranges for the length of the project leaving more granular estimates for each sprint as you plan them. Perhaps you can break a project into rough sprint blocks (i.e. this section of the project is 1-3 sprints) and use this to calculate your range. Ensure that you provide your project estimate with a level of confidence attached. As you learn more from the granular process and as you complete work, you can begin to narrow the range for the overall project estimate and provide a greater level of confidence.
Scrum Planning Poker Guidelines
Photo credit (homepage): Mountain Goat Softare