Comments on: Establishing a Common Baseline for Story Points http://blog.mountaingoatsoftware.com/establishing-a-common-baseline-for-story-points Succeeding With Agile® Thu, 11 Mar 2010 20:54:02 +0000 http://wordpress.org/?v=2.9.1 hourly 1 By: Mike Cohn http://blog.mountaingoatsoftware.com/establishing-a-common-baseline-for-story-points/comment-page-1#comment-67096 Mike Cohn Mon, 01 Mar 2010 13:27:59 +0000 http://blog.mountaingoatsoftware.com/?p=43#comment-67096 Hi Devi- A story that would have been estimated as 6 two sprints ago should still be estimated as 6 today. With relative estimating, new items are estimated in comparison to all previously estimated stories. You build your reference as you go. Find an item you want to call a 2 (leaving room below for ones). Then find something you want to call a 5. Do this through full-team discussion. Then use a technique like <a href="http://www.mountaingoatsoftware.com/topics/planning-poker" rel="nofollow">Planning Poker</a> to estimate the rest of your product backlog. Hi Devi-
A story that would have been estimated as 6 two sprints ago should still be estimated as 6 today. With relative estimating, new items are estimated in comparison to all previously estimated stories. You build your reference as you go. Find an item you want to call a 2 (leaving room below for ones). Then find something you want to call a 5. Do this through full-team discussion. Then use a technique like Planning Poker to estimate the rest of your product backlog.

]]> By: Devi http://blog.mountaingoatsoftware.com/establishing-a-common-baseline-for-story-points/comment-page-1#comment-66740 Devi Wed, 24 Feb 2010 13:16:05 +0000 http://blog.mountaingoatsoftware.com/?p=43#comment-66740 Hi, We have been working on a scrum project for a year now and ideal days seemed to be working. But ideal days have become more of actuals and we have no data for user story sizing to do meaningful trend. Some of my team members do not think story points would solve the problem because it would again be specific to team and we can't be assured that our reference would remain unchanged. for eg. if 2 sprints ago a userstory was say 6 points, today it might be 3 because the team is more comfortable in that type of functionality and would find it relatively easy. Does the story point sizing work only if we have built a reference at the start - with the product backlog? Hi,

We have been working on a scrum project for a year now and ideal days seemed to be working. But ideal days have become more of actuals and we have no data for user story sizing to do meaningful trend. Some of my team members do not think story points would solve the problem because it would again be specific to team and we can’t be assured that our reference would remain unchanged. for eg. if 2 sprints ago a userstory was say 6 points, today it might be 3 because the team is more comfortable in that type of functionality and would find it relatively easy. Does the story point sizing work only if we have built a reference at the start – with the product backlog?

]]> By: Mike Cohn http://blog.mountaingoatsoftware.com/establishing-a-common-baseline-for-story-points/comment-page-1#comment-66070 Mike Cohn Mon, 15 Feb 2010 15:36:03 +0000 http://blog.mountaingoatsoftware.com/?p=43#comment-66070 Hi Sonali-- I want to be careful is saying the baseline is replaced as you do above. It hasn't been replaced. Rather we've added to the set of items we can compare against. Think about this this way: Suppose we are standing in a city park. I point to a tree and say "that tree is 1 unit away." I point to a farther tree and say that tree is 3 away. Looking in the other direction, I point to a table and say that the table is also 3 away. Next you point to something and think it's about as far as the table so you call it 3 away as well. All 3-unit items should be equally distant from us, even though compared to the table rather than to the initially baselined 3. Hi Sonali–
I want to be careful is saying the baseline is replaced as you do above. It hasn’t been replaced. Rather we’ve added to the set of items we can compare against. Think about this this way: Suppose we are standing in a city park. I point to a tree and say “that tree is 1 unit away.” I point to a farther tree and say that tree is 3 away. Looking in the other direction, I point to a table and say that the table is also 3 away. Next you point to something and think it’s about as far as the table so you call it 3 away as well. All 3-unit items should be equally distant from us, even though compared to the table rather than to the initially baselined 3.

]]> By: Sonali http://blog.mountaingoatsoftware.com/establishing-a-common-baseline-for-story-points/comment-page-1#comment-66067 Sonali Mon, 15 Feb 2010 14:47:48 +0000 http://blog.mountaingoatsoftware.com/?p=43#comment-66067 Hi Mike, Thanks for this interesting post. In one of the reply you have mentioned that once we start into iteration we can refer to the recent US implemented in last iteration to compare & to come up with size estimation for the US in current sprint. That means the baseline that would have been established at the beginning of the project can be replaced with the new ones. But does that mean we establish & publish new baseline every time it changes from original or it's left to the team to decide to choose which one to compare with ? Hi Mike,
Thanks for this interesting post. In one of the reply you have mentioned that once we start into iteration we can refer to the recent US implemented in last iteration to compare & to come up with size estimation for the US in current sprint. That means the baseline that would have been established at the beginning of the project can be replaced with the new ones.
But does that mean we establish & publish new baseline every time it changes from original or it’s left to the team to decide to choose which one to compare with ?

]]> By: Kerry Kimbrough http://blog.mountaingoatsoftware.com/establishing-a-common-baseline-for-story-points/comment-page-1#comment-63903 Kerry Kimbrough Mon, 11 Jan 2010 17:00:33 +0000 http://blog.mountaingoatsoftware.com/?p=43#comment-63903 I mentioned some of the many sources of variation that confront relative estimates. I agree relative estimating can be effective when the team can get these variations under statistical control. But how to do that? What I seem to hear most often is "well, it eventually works itself out". But what I often see in practice is "not". Because the team really isn't thinking about it or doesn't know how, the distribution of actual duration around "N story points" has a high variance and velocity is unstable. I understand the 2 levels of estimation and how story pts (relative) are used for backlog and hrs are used for sprints. (Sorry, my previous post confused these.) I understand that story points are intended to quickly capture the intrinsic difficulty of a story (regardless of who does it when). Has anyone tried a direct quantitative estimate of difficulty? Sort of an agile version of function points? (Not that I'd suggest FP, which is problematic in many ways and anyhow not well-suited to a brief planning conversation). I mentioned some of the many sources of variation that confront relative estimates. I agree relative estimating can be effective when the team can get these variations under statistical control. But how to do that? What I seem to hear most often is “well, it eventually works itself out”. But what I often see in practice is “not”. Because the team really isn’t thinking about it or doesn’t know how, the distribution of actual duration around “N story points” has a high variance and velocity is unstable.

I understand the 2 levels of estimation and how story pts (relative) are used for backlog and hrs are used for sprints. (Sorry, my previous post confused these.) I understand that story points are intended to quickly capture the intrinsic difficulty of a story (regardless of who does it when). Has anyone tried a direct quantitative estimate of difficulty? Sort of an agile version of function points? (Not that I’d suggest FP, which is problematic in many ways and anyhow not well-suited to a brief planning conversation).

]]> By: Mike Cohn http://blog.mountaingoatsoftware.com/establishing-a-common-baseline-for-story-points/comment-page-1#comment-63837 Mike Cohn Sun, 10 Jan 2010 16:04:55 +0000 http://blog.mountaingoatsoftware.com/?p=43#comment-63837 Hi Kerry-- The idea of relative estimating being better than absolute is not merely a premise. It has been shown by Lederer and Prasad in "A Causal Model for Software Cost Estimating Error" (1998) and Vicinanza et al. in "Software Effort Estimation: An Exploratory Study of Expert Performance" (1991). I don't consider velocity an unnecessary variable. I call velocity "the great equalizer" because it is what lets a team be able to successfully plan a project as long as their estimates are consistent (even if there is systematic error in those estimates). Being consistent is much easier to achieve and this allows teams to create plans. I don't think it's the foundation of your argument above, but I want to be clear that I advocate story point estimating for user stories (features) and not for tasks. You mention tasks a couple of times. You conclude with a mention again of tasks and saying wouldn't it be better to use tasks. But keep in mind, an agile team plans at two levels: with story points I am talking about plans put together to encompass the next 3-9 months. A typical team would spent a month of effort (up front) if they had to break all the work of the next 9 months into tasks and hour estimates. Release-level planning is to enable prioritization and product decisions. At the start of each sprint the team does do planning at the task/hour level. You may want to take a look at the <a href="http://www.mountaingoatsoftware.com/books/1-agile-estimating-and-planning" rel="nofollow">Agile Estimating and Planning</a> book. Hi Kerry–

The idea of relative estimating being better than absolute is not merely a premise. It has been shown by Lederer and Prasad in “A Causal Model for Software Cost Estimating Error” (1998) and Vicinanza et al. in “Software Effort Estimation: An Exploratory Study of Expert Performance” (1991).

I don’t consider velocity an unnecessary variable. I call velocity “the great equalizer” because it is what lets a team be able to successfully plan a project as long as their estimates are consistent (even if there is systematic error in those estimates). Being consistent is much easier to achieve and this allows teams to create plans.

I don’t think it’s the foundation of your argument above, but I want to be clear that I advocate story point estimating for user stories (features) and not for tasks. You mention tasks a couple of times.

You conclude with a mention again of tasks and saying wouldn’t it be better to use tasks. But keep in mind, an agile team plans at two levels: with story points I am talking about plans put together to encompass the next 3-9 months. A typical team would spent a month of effort (up front) if they had to break all the work of the next 9 months into tasks and hour estimates. Release-level planning is to enable prioritization and product decisions. At the start of each sprint the team does do planning at the task/hour level.

You may want to take a look at the Agile Estimating and Planning book.

]]> By: Kerry Kimbrough http://blog.mountaingoatsoftware.com/establishing-a-common-baseline-for-story-points/comment-page-1#comment-63751 Kerry Kimbrough Sat, 09 Jan 2010 17:27:49 +0000 http://blog.mountaingoatsoftware.com/?p=43#comment-63751 Sorry, I arrived late to the discussion while doing some research on agile estimation. But I'm troubled. Here, the premise is that relative estimations are superior, but I find that assumption very problematic. First, the exemplar may be missing. Second, your info on actual effort for the exemplar may be flawed (especially true in the common case of "Gee, I think I remember when I did something like this"). And finally, the comparability of the task at hand with the exemplar may be sketchy -- it may seem kinda semi-sorta similar, but actually it's a new situation in many ways. In my experience, this "things are always different" aspect is the rule, not the exception. What I see is that the actual pragmatics of sw dev usually make relative estimation unsound. Yet this business of story points introduces all kinds of additional problems (e.g. the topic of this thread) and unnecessary variables (e.g. velocity). Since estimating is really about imagining what will happen in the future, isn't it better work directly with the real world of real tasks and real hours before you? Would truly like to hear your responses, because estimation is a difficult problem, and I'm still looking for more knowledge. Sorry, I arrived late to the discussion while doing some research on agile estimation. But I’m troubled. Here, the premise is that relative estimations are superior, but I find that assumption very problematic. First, the exemplar may be missing. Second, your info on actual effort for the exemplar may be flawed (especially true in the common case of “Gee, I think I remember when I did something like this”). And finally, the comparability of the task at hand with the exemplar may be sketchy — it may seem kinda semi-sorta similar, but actually it’s a new situation in many ways. In my experience, this “things are always different” aspect is the rule, not the exception. What I see is that the actual pragmatics of sw dev usually make relative estimation unsound. Yet this business of story points introduces all kinds of additional problems (e.g. the topic of this thread) and unnecessary variables (e.g. velocity). Since estimating is really about imagining what will happen in the future, isn’t it better work directly with the real world of real tasks and real hours before you? Would truly like to hear your responses, because estimation is a difficult problem, and I’m still looking for more knowledge.

]]> By: Ian Suttle http://blog.mountaingoatsoftware.com/establishing-a-common-baseline-for-story-points/comment-page-1#comment-26546 Ian Suttle Sat, 22 Nov 2008 23:39:25 +0000 http://blog.mountaingoatsoftware.com/?p=43#comment-26546 Inspiring post for getting everyone thinking the same way. This has been a common question amongst people in our org as we introduce story point estimating. I've recently been giving presentations about story points and their benefits to others in our company. I've written up a brief intro to get the basics down here: http://www.iansuttle.com/blog/post/Betting-on-Story-Points.aspx Thanks, Ian Inspiring post for getting everyone thinking the same way. This has been a common question amongst people in our org as we introduce story point estimating.

I’ve recently been giving presentations about story points and their benefits to others in our company. I’ve written up a brief intro to get the basics down here: http://www.iansuttle.com/blog/post/Betting-on-Story-Points.aspx

Thanks,
Ian

]]> By: Mike Cohn http://blog.mountaingoatsoftware.com/establishing-a-common-baseline-for-story-points/comment-page-1#comment-22775 Mike Cohn Mon, 15 Sep 2008 21:31:50 +0000 http://blog.mountaingoatsoftware.com/?p=43#comment-22775 Hi Syed-- Yes, you can create a baseline from these representative stories so your understanding is correct. It's still better to use real ones when you can and you will build up real ones iteration by iteration. Any new story can be compared to any of the old ones so the original baseline become less important over time (as there are many more to compare to). -Mike Hi Syed–

Yes, you can create a baseline from these representative stories so your understanding is correct. It’s still better to use real ones when you can and you will build up real ones iteration by iteration. Any new story can be compared to any of the old ones so the original baseline become less important over time (as there are many more to compare to).

-Mike

]]> By: Syed Rayhan http://blog.mountaingoatsoftware.com/establishing-a-common-baseline-for-story-points/comment-page-1#comment-22773 Syed Rayhan Mon, 15 Sep 2008 18:55:29 +0000 http://blog.mountaingoatsoftware.com/?p=43#comment-22773 Mike, This clarifies a confusion I had about relative estimation. That is a team needs to have a relatively well defined/complete product backlog in place and perform relative estimation before they start working on it. I was not sure to how to perform relative estimation on a continuously growing backlog. Just to make sure I understand what you are saying here, a team or a company can agree on relative sizing of a set of representative stories and then use them to estimate real stories as they come in. That solves our problem. For some of our clients, we do releases every sprint and we do not have stories defined for future sprints well ahead of time. So we endup having only actual estimates (sprint planning) and hence we do not have team velocity. Now we will have one...:-) Thanks a lot as always. Syed Rayhan product: http://www.scrumpad.com company://www.code71.com Mike,
This clarifies a confusion I had about relative estimation. That is a team needs to have a relatively well defined/complete product backlog in place and perform relative estimation before they start working on it. I was not sure to how to perform relative estimation on a continuously growing backlog. Just to make sure I understand what you are saying here, a team or a company can agree on relative sizing of a set of representative stories and then use them to estimate real stories as they come in. That solves our problem. For some of our clients, we do releases every sprint and we do not have stories defined for future sprints well ahead of time. So we endup having only actual estimates (sprint planning) and hence we do not have team velocity. Now we will have one…:-)

Thanks a lot as always.

Syed Rayhan
product: http://www.scrumpad.com
company://www.code71.com

]]>