What is a story point ? November 13, 2007
Posted by editor in Agile Practices, Scrum.trackback
Story point is a arbitrary measure used by Scrum teams. This is used to measure the effort required to implement a story.
In simple terms its a number that tells the team how hard the story is.
In most cases a story point range is
1,2,4,8,16 or X Small, Small, Medium, Large, Extra Large
It is a relative term and does not directly co relate to actual hours . Since story points have no relevance to actual hours, it makes it easy for scrum teams to think abstract about the effort required to complete a story.
This also creates a lot of confusion as most scrum masters who come from a PMP background relate this immediately to hours.
Story points do give some indication of how much time time was spent in a sprint.
Example lets say at the end of a 10 day sprint a team of 4 covers 40 story points.
10 days = 10 * 8 working hours = 80 hours. = 320 total hours as there are 4 developers.
That equated to 160 pairing hours.
160 divided by 40 = 4 hours pair hours per story point.
One issue I’ve encountered in using hours as a measure of effort is, it can be very subjective when using for estimates. In Extreme Programming (XP), developers need to estimate the effort for the stories. The effort in hours could vary from developer to developer. We could attempt to overcome this issue by using story points which can be used as a relative measure between stories. After a few iterations, it would be possible to calculate the equivalent effort in hours per story point.
Nice description of the story point…my team just started using SCRUM to manage our new product line and this post has really helped. Thanks!
I didn’t get what do you mean by pairing hours – You are talking about 2 resources work at a time [Pai programming] ?
Thanks
8 working hours? They don’t eat, talk, think? Auch…
Hummm…
Quite interesting!
I’ll calculate the hours per story point for my team.
Thanks for the post. While I agree calculating story points to hours is interesting it’s also a bit inaccurate as story points are a relative means of estimating. I might estimate something to be a 20 and it takes me 4 hours, and estimate another thing as an 8 and it takes me 6 hours. 28 total points / 10 hours = 2.8 hours / point using your formula. If I apply that to just one story I’m likely not accurate. For instance, if I wanted to say I have a story which I estimate a 20 and believe I’ll spend 2.8 hours / story point, I’ll plan for this story to take 56 hours. But in the example earlier it really took 4. Why? Because it’s relative and by giving it a 20 I’m saying either a) I don’t know enough about the story to be more accurate, b) there’s a lot of risk involved, or c) it’s a lot of work. Story points should really be used for longer term estimating (I believe Mike Cohn suggests the same) and not short term. It’s a trending tool of sorts. If I really need to know how many hours or days something will take I’ll break it down and try to get an estimate in hours or days for that task. Let me know what you think about my post on story points.
Thanks again!
Ian
Ian,
Story points are very useful way to estimate at a gross level / release level. Most useful at a release planning level. In a sprint planning I use it as a tool that can make the planning process efficient.
After the capacity plan is done, the team has an idea. I generally ask the team to pick the first few prioritized stories and size them quickly. This starts a communication in sprint planning between the scrum team and product owner. I think this is the biggest benefit i get out of using story points and sizing.
Instead of this if we use time, the conversation take a different turn. I think in the end it does not matter if a small take 40 hours or a large takes 30 hours. What matters is team used the card and conversation to build software in the two or three weeks and delivers value to the product owner.
[...] members of the team chose a card that represents their estimation. We use story points in the set proposed by Cohn [...]
Hi, I just wanted to mention that we have never used story points – and I still don’t see the value of them. Your post does a good job of explaining what they are, and thank you – but I would love to hear your thoughts on what the whole ‘point’ is.
I have joined an organization that has been ‘scrum-like’ for approximately 18 months. Every one of their teams struggles with story pointing. Many of the team members do not see any value to story pointing (as per Jacobs post) and are unable to differenciate story point from time.
As a seasoned Scrum Master – a team with a stabilized velocity is valuable to me so that I can size up a release quickly and at the high level accurately enough to predict if we will meet dates, to determine dates if scope is set and to keep my upper management highly enformed.
To stop team members from getting hung up and stuck on a story point relating to time, I simply removed the number. We no longer use cards and numbers. We simply size the backlog using ExtraSmall, Small, Medium, Large and ExtraLarge. We have a baseline Medium story which we use for each and every pointing session to start our triangulation for new stories.
For me, I have the numbers assigned to each size, XS-3 | S-5 | M-8 | L-13 | XL-20. Anything over an XL is not a sprintable story for us and can be tagged with a 40 or 100 but basically they need to be broken down and we don’t entertain them into our sprints. I found the meetings less confusing, less frustrating for teams, more effecient and I still have a velocity calculated with each sprint.
thanks fixed