Story points are a unit of measure for expressing an estimate of the overall effort that will be required to fully implement a product backlog item or any other piece of work.

When we estimate with story points, we assign a point value to each item. The raw values we assign are unimportant. What matters are the relative values. A story that is assigned a 2 should be twice as much as a story that is assigned a 1. It should also be two-thirds of a story that is estimated as 3 story points.

Instead of assigning 1, 2 and 3, that team could instead have assigned 100, 200 and 300. Or 1 million, 2 million and 3 million. It is the ratios that matter, not the actual numbers.

What Goes Into a Story Point?

Because story points represent the effort to develop a story, a team’s estimate must include everything that can affect the effort. That could include:

The amount of work to do

The complexity of the work

Any risk or uncertainty in doing the work

When estimating with story points, be sure to consider each of these factors. Let’s see how each impacts the effort estimate given by story points.

The Amount of Work to Do

Certainly, if there is more to do of something, the estimate of effort should be larger. Consider the case of developing two web pages. The first page has only one field and a label asking to enter a name. The second page has 100 fields to also simply be filled with a bit of text.

The second page is no more complex. There are no interactions among the fields and each is nothing more than a bit of text. There’s no additional risk on the second page. The only difference between these two pages is that there is more to do on the second page.

The second page should be given more story points. It probably doesn’t get 100 times more points even though there are 100 times as many fields. There are, after all, economies of scale and maybe making the second page is only 2 or 3 or 10 times as much effort as the first page.

Risk and Uncertainty

The amount of risk and uncertainty in a product backlog item should affect the story point estimate given to the item.

If a team is asked to estimate a product backlog item and the stakeholder asking for it is unclear about what will be needed, that uncertainty should be reflected in the estimate.

If implementing a feature involves changing a particular piece of old, brittle code that has no automated tests in place, that risk should be reflected in the estimate.

Complexity

Complexity should also be considered when providing a story point estimate. Think back to the earlier example of developing a web page with 100 trivial text fields with no interactions between them.

Now think about another web page also with 100 fields. But some are date fields with calendar widgets that pop up. Some are formatted text fields like phone numbers or Social Security numbers. Other fields do checksum validations as with credit card numbers.

This screen also requires interactions between fields. If the user enters a Visa card, a three-digit CVV field is shown. But if the user enters an American Express card, a four-digit CVV field is shown.

Even though there are still 100 fields on this screen, these fields are harder to implement. They’re more complex. They’ll take more time. There’s more chance the developer makes a mistake and has to back up and correct it.

This additional complexity should be reflected in the estimate provided.

Consider All Factors: Amount of Work, Risk and Uncertainty, and Complexity

It may seem impossible to combine three factors into one number and provide that as an estimate. It’s possible, though, because effort is the unifying factor. Estimators consider how much effort will be required to do the amount of work described by a product backlog item.

Estimators then consider how much effort to include for dealing with the risk and uncertainty inherent in the product backlog item. Usually this is done by considering the risk of a problem occurring and the impact if the risk does occur. So, for example, more will be included in the estimate for a time-consuming risk that is likely to occur than for a minor and unlikely risk.

Estimators also consider the complexity of the work to be done. Work that is complex will require more thinking, may require more trial-and-error experimentation, perhaps more back-and-forth with a customer, may take longer to validate and may need more time to correct mistakes.

All three factors must be combined.

Consider Everything in the Definition of Done

A story point estimate must include everything involved in getting a product backlog item all the way to done. If a team’s definition of done includes creating automated tests to validate the story (and that would be a good idea), the effort to create those tests should be included in the story point estimate.

Story points can be a hard concept to grasp. But the effort to fully understand that points represent effort as impacted by the amount of work, the complexity of the work and any risk or uncertainty in the work will be worth it.

Would you like to include comments?

Tagged:

About the Author

As the founder of Mountain Goat Software, Mike Cohn specializes in helping companies adopt and improve their use of agile processes and techniques to build extremely high-performance teams. He is the author of User Stories Applied for Agile Software Development, Agile Estimating and Planning, and Succeeding with Agile. Mike is a founding member of the Agile Alliance and Scrum Alliance. He is also the founder of FrontRowAgile.com, an online agile training website. He can be reached at [email protected] or connect with Mike on Google+.

Currently we are using 'powers of 2' method for estimating user stories. Also, we think one resource can complete 16 story points task within a day and since we follow 10-Sprint, one resource get 160 story points for a Sprint. As we have 3 resources, we calculate total velocity for a Sprint as 160 * 3 and that is 480 story points. I would like to get your opinion on the method we follow to estimate a task and calculating story points and velocity.

Thanks!Kapila

Posted by Kapila Witharana on 2016-12-02 01:15:56

Thanks, Alex.

Yes, I would have everyone estimate together—yes, even the iOS people help estimate the web work. The key though is that iOS people (as this example) should help on the web estimates. The drivers of the web estimate would be the web developers.

I want the iOS people there, though, because as one example the iOS people may hear things that influence their own estimate. For example, they hear a web developer talk about how they need to do such and such on a story and the iOS people realize they need to do the same.

I don’t see any issue with the size of the stories being different. Some things will take longer on iOS and some will take longer on web. So be it.

The issue there may be that you seem to imply you have forced “the reference story” to be the same on each platform. If that means you say something like “do this on iOS and do this on web equals 5 points” then that is a problem right there. Doing that thing might be 5 on iOS and 3 on web. Given that points are *effort* (see my numerous posts on that), I would fully expect that to be the case.

Posted by Mike Cohn on 2016-11-28 19:45:30

Hi Mike,

Thank you for the huge amount of useful information you've helped us with.

I'm trying to help my team shift from man-days and hours to story points. I'm quite familiar with the concept and I'm pretty sure I know how this will help us down the line, but that's not what I wanted to ask you.

The team consists of 6 devs (2 iOS, 2 web, 2 back-end), 2 QA, the SM and a BA (me). Currently, each front-end platform estimates their own work, as they are the most capable and have the best understanding of the code. Also, the stories are sometimes for one platform, but there are features that need to be implemented on both platforms at the same time.

How do you think we should approach estimations? Should each platform estimate separately (iOS+QA)? Or should I focus on having stories for all platforms at the same time and have them all estimate together? What happens if the size of the stories are different when it comes to each platform, although the reference story was the same size for each of the platforms when implemented?

Thanks!Alex

Posted by Alex Marciuc on 2016-11-28 05:22:17

Thanks, Geotar. I haven’t really thought of anything else.

Posted by Mike Cohn on 2016-10-04 18:10:01

Hi Mike,

This is a great and simple way to explain the story points. I want to know if besides the amount, complexity, and risk/uncertainty of work, is there anything else that finds its way into the story points?

Posted by Getoar Krasniqi on 2016-10-04 18:08:05

Hi James—

No, I would not include them. It’s a well-established best practice from even before agile was around that those who will do the should estimate the work. Since stakeholders and customers don’t do the work, they don’t participate in estimating it. There should be at least one other post on this site specifically about who participates.

And thanks: I’m glad you found this helpful.

Posted by Mike Cohn on 2016-10-02 18:08:54

Hello Mike,

I am a MBA student concentrating in Project Management, so please bear with me if my questions are elementary. When you discuss factoring in risk and uncertainty when assigning story point value, would you include the customers and all other stakeholders in the point estimate? I feel that a new team that hasn’t worked together previously might find it difficult to measure their effort required to complete a story or iteration and consequently difficult to assign story points. In your experience would you include all stakeholders in every story point assignment conversation? I found your three components of story point estimation to be very useful, and will certainly apply them to future agile projects.

Posted by JAMES ROGERS on 2016-10-02 18:06:31

I found this new website on agile and which I think everyone should go through:www.agilelove.com

Posted by Arjun singh on 2016-09-24 23:21:53

Thanks, Nat.

Yes, I recommend looking for a 2 (“small but not the smallest”) and then a 5 (about twice as much effort as the two). I do that just by discussion (no estimation techniques like Planning Poker or otherwise) and then I have the team use Planning Poker (or whatever they prefer).

“Down the road” I don’t think you need to change because the number wasn’t really “arbitrary.” Most teams can find something “small but not the smallest.” So the above works really well.

Worst case is that perhaps 5-15 items in (your first estimates) you may discover your baseline is wrong and you want to change it. Go ahead. Maybe the team didn’t leave enough room below the 2. Change that to a 5 and revise the estimates (that will go quickly since they are all understood relatively already). You won’t discover the need to do this 100 items it. It happens in the first 5-15 or not at all.

Posted by Mike Cohn on 2016-09-05 09:42:13

Mike, great intro to story points. Quick question. For a team that has no experience with story points estimating is there a general rule of thumb to use for coming up with an initial estimate of capacity for the team?

Down the road we'll be able to use historical velocity for estimates but in the beginning is there an idea that is better than an arbitrary number?

Thanks!

Posted by Nat Thompson on 2016-09-05 08:44:57

Hi, Mike.We will start building Srcum process on the project.We will estimate stories. Product owner add new story. This story will be easiest that all the rest.Do we need re-estimete previous stories? or Do we need estimate only new story?

Posted by Anna on 2016-09-05 04:51:58

Thanks. And, yes, you can. Thanks for checking.

Posted by Mike Cohn on 2016-09-01 11:52:15

Hi Mike,Thanks for another great explanation of Scrum concepts.I would like to ask for your permission to publish this article on our internal wiki, including URL to the original source.

I'll take a look at those two recommendations.I'm mostly interested in capturing data to create motivational awareness to drive improvements at a team level but sometimes, someone from outside the team comes looking for other metrics.

Thanks for taking the time out to respond.

Posted by Gabriel Louët-Feisser on 2016-08-30 04:51:24

Should teams include release in their definition of "done"?

I'm torn between two schools of thought here: if the release activity is done as a chore, it reduces velocity so it might encourage the team to streamline or automate (or encourage stakeholders to ask why we aren't focusing on reducing this overhead, as they'll see fewer stories being picked up in the next sprint).

At the same time, if we don't assign points to release work, velocity loses predictive value because the release cost of each system isn't uniform and is significant relative to the size of the team.

The other problem of course is getting stories accepted when "done" includes deployment...

Posted by Dave McCraw on 2016-08-30 03:20:50

What I’d like to say is “come observe us.” But I understand you or whoever is asking likely won’t like that answer.

Measuring productivity of knowledge worker is a problem that has not yet been solved in any industry. I think a starting point is creating a balanced scorecard for the project or team—see the next to last chapter in Succeeding with Agile.

Additionally, there’s something called Data Envelopment Analysis which holds out some promise in this area. But it’s much more an academic thing so far and hasn’t really been used for that in industry. I tried hiring a professor to do research into DEA about a year ago but she turned out to not be available. If you need something, look into DEA but it still suffers from a problem of needing an output metric.

Posted by Mike Cohn on 2016-08-29 20:40:12

If the team are asked to back up the observation that they are getting two, or three or more times as much done as they were a year ago, any suggestions on how they might to that?Sometimes we are in an environment where we have try and draw a graph..! :-0

Posted by Gabriel Louët-Feisser on 2016-08-29 08:41:39

Thanks, Gabriel.

Excellent question and observation. I’ve struggled with this one over the years, too. But the team should call Story X 3 points. Story X is not (at the moment) the same expected effort that Story A was back when it was estimated as 5. Story X will take less time than A because of this so it gets fewer points.

That isn’t likely much of an issue because velocity is not a good way to measure productivity improvements over time anyway. When that is done, there inevitably comes pressure from someone outside the team to improve and estimates become inflated. Similarly there’s a lot of “junk” that gets into team members heads that affects estimates such that the productivity gains don’t show up in velocity anyway.

I’ve worked with teams for which we could bring 100 outside observers and every one would have no doubt the team is getting two, or three or more times as much done as they were a year ago. And the team agrees. No doubt. Yet even on those types of teams, velocity might be up 50%. So I would never use velocity for looking at long term improvements anyway.

Posted by Mike Cohn on 2016-08-28 23:00:12

We usually only work on a dozen items for the sprint... so the re-estimation probably only takes an hour or two. It's not a big penalty for us.

As for planning, i'm currently updating my gantt chart for the next 7 years. Fun times.

Posted by Aaron Steinmetz on 2016-08-28 22:45:31

Hi Ezio: I’m not aware of anything exactly like this. I encourage you to experiment and see how it goes.

Posted by Mike Cohn on 2016-08-25 09:34:34

I'm guessing you need to re-estimate a lot then. What about when your best developers are on sick leave in a particular sprint, or for whatever other reason they can't work on the estimated items? What about accumulating technical debt? What about the effect of learning and discovering better / easier / faster ways to implement previously estimated items? There's a lot of reasons why early estimates could become irrelevant. Doesn't it take your team too much time to do all that work again?

You suggested that the reason behind this is your organization's budgeting scheme. Have you tried negotiating a different one? One that doesn't require that much upfront, detailed planning?

Posted by Jakub Zienkiewicz on 2016-08-25 08:23:37

Hi Mike,Informative blog as always.One area I am struggling with is uncertainty, points decay and how this reflects a team's performance. A team sizes Story A at 5 points. Story A includes some uncertainty as no one on the team is very familiar with the new technology (or part of the domain) required to complete the story.A sprint or two down the road, they are grooming the backlog and start to groom Story X and realise it is very similar to Story A. Should they size Story X as 5 points (same as Story A) or less, say 3 points? The uncertainty has reduced due to the team's experience from working on Story A.If the size is 3 for Story X, we lose visibilty on how the team is improving.

Posted by Gabriel Louët-Feisser on 2016-08-25 08:20:40

Hi Mike, I appreciate your "linear" definition of Story Point (2 SP = 1+1 SP) and I see the challenge to assess "how complex" is a single SP. I tried to solve this problem, counting story points based upon how many test case will be needed to test the SP implementation itself. Say: I need a single test case -> 1 SP (it's the case of your simple page with 1 o many independent text fields, with non cross-field validation); a simple C-R-U-D (with search-list) function (using a function template): 5 SP. Implementation of a complex requirement: as many SP as many different test case will be needed. I understand that I am turning a SP into a "test point" but probably it's easier for anyone (even for a Customer) to understand that a function is "more complex" if I (the developer) can demonstrate that I will need to run many different test cases to release it. And no-one will argue that test case are not needed. In your experience, do you know if someone has already experienced sw estimate based upon Test Point metrics? I see some advantages in using this metric, tied to the SP concept.

Posted by Ezio Giammarini on 2016-08-25 04:22:16

We use story points for everything at the start of the project, all stories, which is really hours. They are estimates (or more rightly, allocations). This is needed to set a budget. Before a sprint starts, we review all stories in that sprint and re-estimate points. However, the story points are simply a number of hours. For the last 3 sprints, we've done an average of 6.6 points per day, and my next sprint coming up is 20 man days of work... so i'm targetting "132 points".

Posted by Aaron Steinmetz on 2016-08-25 01:56:07

No need to apologize :-) I can imagine your frustration if you've been trying to improve something for years with no result.

What I meant by points to time relation not being a good idea, I meant fixing a story point to a unit of time. It's pretty much never a direct relation and trying to use story points like that usually leads to trouble. As Mike pointed out in another comment, you might as well be estimating using hours and drop the story points altogether in that case.

In our team we estimate in story points as ballparks, and use those mainly to help the Product Owner prioritize the backlog by showing the value/cost ratio. Of course, we also use it as a guideline for filling the sprint backlog, but it's still not set in stone at this point. During the second part of sprint planning the team estimates tasks in hours. If it turns out to be more work than first anticipated, we notify the PO and renegotiate the sprint scope. That's the first moment we think about the effort strictly in terms of time it takes to develop the feature. It's a lot of work to do it earlier (that might go to waste if we never decide to develop it) and usually it's pretty inaccurate. Then again, we don't need to synchronize our delivery plans with a lot of other teams. Not sure if you could apply the same approach in your setup.

Posted by Jakub Zienkiewicz on 2016-08-25 01:06:14

It does yes!

Posted by Quentin Désert on 2016-08-24 20:25:08

Thanks for understanding the need for the task/story clarification. When I talk to people about this, they say “task” all the time when they mean story. But 1 time out of 100, they really meant task so I always try to clarify just as an aside before going into the real explanation.

I’m glad my silly octopus example helps. It’s too silly for some people but it really does illustrate the idea of the developer who is 4x the speed of another developer!

Posted by Mike Cohn on 2016-08-24 20:19:30

For the 'task' vs 'story', I actually meant story, just a misword, but you're right to correct me :)About the rest, thanks for your very complete answer, that's very clear! Love the silly octopus example.

Posted by Quentin Désert on 2016-08-24 20:15:41

First, I’d never use story points on a task. (See https://www.mountaingoatsoftwa... for the difference.) A typical story will be worked on by 3-4 people. So even if it gets, let’s say, two programmers who code at different rates, either will work with the same tester, database person, and designer. (Just an example.)

Second, if one programmer is twice as fast as another at the work of Story A then the same programmer is likely twice as fast at Story B.

That’s not always true, though. Teams should always make an assumption though that the right person for the job will do the job—e.g., we don’t have our UI designer go master SQL and work on one database thing this sprint. Instead we wait to do that thing next sprint when the database engineer is available. Addressing that is a *planning* issue. That is, if we’re chronically understaffed by one resource, that needs to be considered in the plan (how long will all this take) but it doesn’t affect the size of the work (the number of story points).

The situation you describe happens a lot in real life but it is almost always because each person is thinking “This will take me x [or y] hours” and x and y are different. If they instead think “This is twice the effort of that other story, I’ll put twice the points on it” the two developers will be able to agree on a common effort estimate.

The silly (but helpful!) example I like is that an octopus (with 8 arms!) and I discuss washing a car. The octopus can wash the car a lot faster than I can. (I’m assuming it can hold a sponge! Work with me here! :) So the octopus and I disagree on the time to wash a small car but we can agree that washing the small car will take half the time of some bigger car.

Posted by Mike Cohn on 2016-08-24 19:46:29

Good, Aaron. If the programmers resist, have them find other things they can do to help improve the imbalance. For example, write “perfect” code. That takes them longer and testers find fewer bugs so there’s less re-test time. (A big issue with manual testing.) Have them write code that is easier to test (takes them longer; speeds the test effort). Pairing is a way to do that. Have them look at creating (or incorporating) automation frameworks that help the testers. They don’t have to run manual tests. Good luck.

Posted by Mike Cohn on 2016-08-24 18:59:41

Thanks for the reply Mike (and others too). I'd written off the idea of having every members effort total together for the sprint, as the logistics of managing slack/downtime seem challenging. Having said that, I will consider it more as the current method is not working, and several have said this is the direction we should head - so, I will try it.

Thankyou all.

Posted by Aaron Steinmetz on 2016-08-24 18:25:25

Automation testing - it's an excellent idea, there are a few political roadblocks in this area, but yes it's something i've been pushing for for a while now. Ironically we actually had it going, but let it fall by the wayside (our hands were tied).

Posted by Aaron Steinmetz on 2016-08-24 18:22:24

An argument for hiring more. LOL. I've been arguing with management about it for over ten years, as have many others, and it just falls on deaf ears.

As for needing to relate estimates to time... why else would i even bother wasting any time doing the estimation in the first place? I need to know when a sprint is going to finish, and what features will be in it, so i can schedule the various teams around each other and product releases. (apologies if i'm coming across rude, it's not intended, i'm just frustrated).

Posted by Aaron Steinmetz on 2016-08-24 18:20:52

Hi Mike. And what about if someone find a task very complex (because he's never done anything like that), so it will imply more effort and risks for him, but another member of the team find it quite trivial because he already did this kind of thing several times? Then even if the complexity is there, the estimation could be a 5 for the first one and a 2 for the other one (or even more distant numbers). How can they agree? Should it be the higher number?

Posted by Quentin Désert on 2016-08-24 13:41:55

Yes, we are estimating effort. I’ve written about that extensively in other posts on this blog. You want to estimate the effort as influenced by risk, uncertainty and complexity. If those things do not translate into additional effort then I would ignore that impact.

Posted by Mike Cohn on 2016-08-24 09:00:20

Hi Jim: That’s on my “Content Backlog” to write about someday but I try to keep comments relevant to the specific topic of the post. Short answer, though, is that I’m generally not a fan and I hate things that are named just to get attention. It does, however, attempt to solve a real problem that many teams suffer: spending too much time estimating. Probably one out of 50 companies I work with gets advice from me of “spend more time estimating.” Most spend too much time but going to an extreme of never estimating would not be good. Just because something is hard, doesn’t mean our response should be to immediately give up on doing. Anyway, I’ll get a post on it at some point.

Posted by Mike Cohn on 2016-08-24 08:58:44

The general principle is to estimate the size of the work then derive the duration. No, of course not, story points and function points are not the same thing.

Posted by Mike Cohn on 2016-08-24 08:55:35

Hi Aaron—

As others have indicated, the real issue is an imbalance of specialties here. In one of my weekly tips to subscribers (https://www.mountaingoatsoftwa... <https: www.mountaingoatsoftware.com="" email-tips="">) I shared the idea that “at the end of a sprint, we’re all testers.” I suggest you try to instill that mindset in your team. If every sprint the programmers get 10% further ahead than the testers, why keep doing that?

As for your specific questions, you should estimate the effort to go from idea (on the product backlog) to full implementation. Think about if you had purely a programming-only estimate. What could you possibly do with it that would be useful? Divide it by velocity and get a date? Who cares about that date? All it would tell is when you’d have untested code. You want to estimate the full effort.

Posted by Mike Cohn on 2016-08-24 08:53:51

Perfect. Yes, one of the things to consider is how much you think a team will improve after the first two. If they are the teams first-ever sprints, velocity tends to increase as team members start to figure things out.

Posted by Mike Cohn on 2016-08-24 08:50:32

Totally agreed, I would never use t-shirts for more than 1 to 2 sprints but it's a quick easy way to get into relative estimating for a new team.

Jim

Posted by Jim Buckley Barrett on 2016-08-24 08:26:29

Tee shirt sizes can be a good way to get started with the idea of relative estimating. But they suffer from not being additive. I've written about them at https://www.mountaingoatsoftwa...

Posted by Mike Cohn on 2016-08-24 06:38:43

Hi Mike, Nice explanation but I think that Story Point talks only about the amount of work to do. Why? If you look for any risk, uncertainty or complexity then every of this factors have direct impact for the amount of work to do. Nothing more.

Posted by Jarek on 2016-08-24 06:05:27

Mike, what is your take on No Estimates? Personally I don't see the benefit other than the team frees up some time during the sprint on refinement.

Posted by Jim Buckley Barrett on 2016-08-24 04:23:51

Matt, have you considered using t-shirt sizes XS, S, M, L, XL , XXL for new teams instead?

Posted by Jim Buckley Barrett on 2016-08-24 04:12:35

Aaron,

In the Scrum guide it states that everyone on the team is considered a developer and no other title , so there should not be a QA/Tester sub team within the team. While estimating the story/backlog item everything that is needed to get the story to the acceptance of DONE, should be taken into the consideration by the whole team. the whole scrum team must understand the work involved in completing any backlog/story.

If your developers have spare time why not have them work on automation testing reducing in the long run the overall time required for manual testing?

Posted by Jim Buckley Barrett on 2016-08-24 04:10:54

Your estimates should include testing effort, yes. But not exclusively the testing effort, the whole effort it takes to get the item to Done. Are you trying / required to directly relate your estimates to time? That's usually not a good idea.

In general, it seems that you have a deeper problem to deal with than your estimates. If your delivery is frequently delayed by incomplete testing, make an argument for hiring more. Or investing in test automation.

Posted by Jakub Zienkiewicz on 2016-08-24 03:31:12

Thank you Etta for bringing this aspect and thank you Mike for clarifying this so imporant a relationship.

Posted by Shashank Jain on 2016-08-24 01:07:45

Mike,Thx indeed for the post.A basic doubt. I have known function points (FP) as being a measure of size only. This size then gets "adjusted" (up or down) for complexity factors to arrive at the final size (in FP's). The FP's then get translated to effort using productivity based on platform and other considerations. If Story Point is an effort measure (and not a pure size measure), is it apple-to-apple to compare story points (effort measure) with function points (size measure)?Rgds,Shiv Sivakumar.

Posted by Shiv Sivakumar on 2016-08-24 00:51:44

My team is imbalanced because we have too many developers and not enough testers. The work to test certain stories can vary significantly (and can be more than the coding effort in many instances). Should point estimates be inclusive of testing effort... or only the developer effort (such that testing is considered simply an overhead of the whole process.... such as sick days).

Alternatively, should we actually estimate based on the Testers efforts, rather than the developers? Since the testers are the ones always falling behind? My problem with this would become idling developers, rather than stressed out testers... perhaps a better problem to have overall, however managements 'perceived throughput' would be worsened.

Another option would be to have developers to testing when they have spare time (obviously not on their own code), however devs cost more than testers, and this would affect budgets (they are actually different department budgets)

Thoughts?

Posted by Aaron Steinmetz on 2016-08-24 00:48:19

I think as you rightly pointed out velocity is a great equalizer.We actually measure our effort in the first couple of iterations and we come up a reliable schedule and effort to complete the remaining tasks. The key point here is to be watchful on how it goes in the first one or two iterations.

Mike, When the team carryover a story across a Sprint because they could not complete it in the Sprint, should we discount the story points accordingly on the new Sprint?

Posted by Nevetha on 2016-08-23 21:45:53

Thanks for the feedback and ideas. So much conflicting information out there about how to get the team started on story points. Regards

Posted by Matt on 2016-08-23 18:54:14

Thanks, Greg. Yes, story points and function points are, at their most basic, both attempts to create a size metric for software projects.

Posted by Mike Cohn on 2016-08-23 18:20:23

No, it’s actually a horrible place to start. If you are going to anchor such that 1 point = x hours, just use hours. Once you’ve done that there is absolutely no reason to use points as everyone will just be doing that conversion in their heads.

Plus, unless everyone performs identically, there’s no way that one story equals x hours for *every* person on the team. I’ve written elsewhere about the best ways to get started. (Short version: Find something “small but not the smallest” and call it a 2. Get everyone to agree that however big they think that is, it’s a 2. Then find something about twice as much effort and call it a five.)

Posted by Mike Cohn on 2016-08-23 18:00:40

But isn't that as good a place to start as any when trying to define some benchmark stories to measure against? Once benchmark stories are in place and the team gets used to the idea then the comparison to time/days starts to shift.But you need to start somewhere.

Posted by Matt on 2016-08-23 17:36:27

Absolutely. Saying something is 300 story points is like telling someone a book is 300 pages. It’s pretty meaningless unless accompanied by velocity or pages read per hour.

My book goes into this a bit but much newer thoughts on release planning are in the video course at https://www.frontrowagile.com/... <https: www.frontrowagile.com="" courses="" agile-estimating-and-planning="" table-of-contents#preview=""> as well as in various pages on this site.

Posted by Mike Cohn on 2016-08-23 16:33:18

Mike, Nice explanation. Although I know that "one story point doesn't equal one day", the challenge becomes how to get the budget for the project if all you have for an estimate is points.

Posted by Etta Wilson on 2016-08-23 15:05:37

I like it... it reminds me of a previous project when we used "function points" to help us estimate the size of a work effort. I recall, as you said, relative sizing was important. And so to achieve consistency across work efforts, we used the same people to provide the estimates using the same criteria (for a "point").

Posted by Greg McDaniel on 2016-08-23 14:15:06

Ha! Me, too! Great point, Barnaby. Thanks.

Posted by Mike Cohn on 2016-08-23 13:56:09

If I had a pound for every time somebody had asked me if "one story point equals one day" I would be rich and would no longer need to work :)