Comments on: Is It a Good Idea to Establish a Common Baseline for Story Points? http://blog.mountaingoatsoftware.com/is-it-a-good-idea-to-establish-a-common-baseline-for-story-points Succeeding With Agile® Fri, 10 Feb 2012 03:51:54 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Mike Cohn http://blog.mountaingoatsoftware.com/is-it-a-good-idea-to-establish-a-common-baseline-for-story-points/comment-page-1#comment-339546 Mike Cohn Sat, 07 Jan 2012 22:16:57 +0000 http://blog.mountaingoatsoftware.com/?p=44#comment-339546 Hi Shanthi-- There may not be much harm in that but there's certainly no benefit. If you're going to say one point = one ideal day, just call them ideal days and forgo the benefits of story points. I do sometimes start teams that way--when necessary--but I quickly try to get them out of that mode. Hi Shanthi–
There may not be much harm in that but there’s certainly no benefit. If you’re going to say one point = one ideal day, just call them ideal days and forgo the benefits of story points. I do sometimes start teams that way–when necessary–but I quickly try to get them out of that mode.

]]> By: Shanthi Dev http://blog.mountaingoatsoftware.com/is-it-a-good-idea-to-establish-a-common-baseline-for-story-points/comment-page-1#comment-339469 Shanthi Dev Sat, 07 Jan 2012 20:06:59 +0000 http://blog.mountaingoatsoftware.com/?p=44#comment-339469 What is the harm in "one story point = one day of ideal dev work"? Why cannot a story point be simple enough so everyone understands it? What is the harm in “one story point = one day of ideal dev work”?
Why cannot a story point be simple enough so everyone understands it?

]]> By: Mike Cohn http://blog.mountaingoatsoftware.com/is-it-a-good-idea-to-establish-a-common-baseline-for-story-points/comment-page-1#comment-223906 Mike Cohn Sun, 19 Jun 2011 20:01:12 +0000 http://blog.mountaingoatsoftware.com/?p=44#comment-223906 Juan-- The blog post I referenced covers what to select as the stories to use as the baseline: <blockquote>Not each estimator needs to understand every item but most people should understand most items. The items being estimated do not need to be new items; some could be from a project finished recently that many estimators remember or worked on. Some items could be artificial; perhaps the team is asked to estimate, “a typical transaction activity report.” If that meant something to most estimators, it would be a good candidate item.</blockquote> The goal is not the perfect set of stories for one team but a reasonable set that most people can understand most of them. Juan–
The blog post I referenced covers what to select as the stories to use as the baseline:

Not each estimator needs to understand every item but most people should understand most items. The items being estimated do not need to be new items; some could be from a project finished recently that many estimators remember or worked on. Some items could be artificial; perhaps the team is asked to estimate, “a typical transaction activity report.” If that meant something to most estimators, it would be a good candidate item.

The goal is not the perfect set of stories for one team but a reasonable set that most people can understand most of them.

]]> By: Juan http://blog.mountaingoatsoftware.com/is-it-a-good-idea-to-establish-a-common-baseline-for-story-points/comment-page-1#comment-223902 Juan Sun, 19 Jun 2011 19:55:10 +0000 http://blog.mountaingoatsoftware.com/?p=44#comment-223902 Hey Mike. I have already read that other post :-) (came to this one through the other). You stated " (That’s an oversimplification–you want multiple stories to make up a baseline, not just one.) ". What would the criteria to choose those stories be? Would you start with the ones providing top business value to the customer for example? I can think of a logon. I would not believe that US having to much business value to the customer, comparing to some other feature an application might have... What is tough for me is to imagine how that set of US can serve as a good baseline for new teams in the way the US you choose can reflect something that makes sense, again as a good baseline. Hey Mike.

I have already read that other post :-) (came to this one through the other).

You stated ” (That’s an oversimplification–you want multiple stories to make up a baseline, not just one.) “. What would the criteria to choose those stories be? Would you start with the ones providing top business value to the customer for example? I can think of a logon. I would not believe that US having to much business value to the customer, comparing to some other feature an application might have… What is tough for me is to imagine how that set of US can serve as a good baseline for new teams in the way the US you choose can reflect something that makes sense, again as a good baseline.

]]> By: Mike Cohn http://blog.mountaingoatsoftware.com/is-it-a-good-idea-to-establish-a-common-baseline-for-story-points/comment-page-1#comment-222798 Mike Cohn Fri, 17 Jun 2011 15:39:38 +0000 http://blog.mountaingoatsoftware.com/?p=44#comment-222798 Hi Juan- I'm glad you enjoy the blog. Thanks. In a situation like you describe you'll want to have a standard meaning for a story point. I don't necessarily mean saying "one story point = one day of work" as teams try. But a meaning like "one story equals that logon story we did for client XYZ a year ago." Then all teams can estimate relative to that. (That's an oversimplification--you want multiple stories to make up a baseline, not just one.) For more on that topic see this blog post on <a href="http://blog.mountaingoatsoftware.com/establishing-a-common-baseline-for-story-points" rel="nofollow">establishing a common baseline for story points</a>. Hi Juan-
I’m glad you enjoy the blog. Thanks.

In a situation like you describe you’ll want to have a standard meaning for a story point. I don’t necessarily mean saying “one story point = one day of work” as teams try. But a meaning like “one story equals that logon story we did for client XYZ a year ago.” Then all teams can estimate relative to that. (That’s an oversimplification–you want multiple stories to make up a baseline, not just one.) For more on that topic see this blog post on establishing a common baseline for story points.

]]> By: Juan http://blog.mountaingoatsoftware.com/is-it-a-good-idea-to-establish-a-common-baseline-for-story-points/comment-page-1#comment-222781 Juan Fri, 17 Jun 2011 15:02:43 +0000 http://blog.mountaingoatsoftware.com/?p=44#comment-222781 Hi Make, Great Blog!! Question: What happens when you are an outsourcing development company and you provide service to a huge different customers from different industries, requiring expertise in different technologies, management practices and Agile methodologies knowledge? not only thinking about customer side, what happens inside the company with all those teams with so different skills and capabilities? How you measure a standard story point baseline for estimation with the above scenario? This can be great for new proposal effort estimations for this environment... Hi Make, Great Blog!!
Question: What happens when you are an outsourcing development company and you provide service to a huge different customers from different industries, requiring expertise in different technologies, management practices and Agile methodologies knowledge? not only thinking about customer side, what happens inside the company with all those teams with so different skills and capabilities?

How you measure a standard story point baseline for estimation with the above scenario? This can be great for new proposal effort estimations for this environment…

]]> By: Mike Cohn http://blog.mountaingoatsoftware.com/is-it-a-good-idea-to-establish-a-common-baseline-for-story-points/comment-page-1#comment-140104 Mike Cohn Tue, 25 Jan 2011 06:08:24 +0000 http://blog.mountaingoatsoftware.com/?p=44#comment-140104 Hi Daryl-- You create the baseline so you can play Planning Poker. Without an established baseline you can't. Story points can be used to allow people with different skill levels to estimate commonly. Hi Daryl–
You create the baseline so you can play Planning Poker. Without an established baseline you can’t. Story points can be used to allow people with different skill levels to estimate commonly.

]]> By: Daryl http://blog.mountaingoatsoftware.com/is-it-a-good-idea-to-establish-a-common-baseline-for-story-points/comment-page-1#comment-140034 Daryl Tue, 25 Jan 2011 02:33:08 +0000 http://blog.mountaingoatsoftware.com/?p=44#comment-140034 Hi Mike, There are some concerns about baselining user stories because of the different skill levels in a team. Would baselining affect the results of poker planning? And how do you inform the team that this would not lose the value of using user story? Thanks, Daryl Hi Mike,

There are some concerns about baselining user stories because of the different skill levels in a team. Would baselining affect the results of poker planning? And how do you inform the team that this would not lose the value of using user story?

Thanks,
Daryl

]]> By: Mike Cohn http://blog.mountaingoatsoftware.com/is-it-a-good-idea-to-establish-a-common-baseline-for-story-points/comment-page-1#comment-66587 Mike Cohn Mon, 22 Feb 2010 14:04:48 +0000 http://blog.mountaingoatsoftware.com/?p=44#comment-66587 Hi Chris-- That is exactly how I use function points. I documented a case study of measuring productivity this way in <a href="http://www.mountaingoatsoftware.com/books/2-user-stories-applied-for-agile-software-development" rel="nofollow">User Stories Applied</a>. Thanks for sharing your thoughts here. Hi Chris–
That is exactly how I use function points. I documented a case study of measuring productivity this way in User Stories Applied. Thanks for sharing your thoughts here.

]]> By: Chris Chan http://blog.mountaingoatsoftware.com/is-it-a-good-idea-to-establish-a-common-baseline-for-story-points/comment-page-1#comment-66569 Chris Chan Mon, 22 Feb 2010 05:34:06 +0000 http://blog.mountaingoatsoftware.com/?p=44#comment-66569 If the organization really need to compare productivity and performance across multiple independent teams, then one approach could be to use function points only after the user story has been shipped. i.e. Do not use function points as estimates of future work, but as estimates of what was built and implemented. And if you were to be really cautious as not disrupt the team's approach (eg cutting corners) would be to perform the function point count only after the project is completed. If the organization really need to compare productivity and performance across multiple independent teams, then one approach could be to use function points only after the user story has been shipped.

i.e. Do not use function points as estimates of future work, but as estimates of what was built and implemented. And if you were to be really cautious as not disrupt the team’s approach (eg cutting corners) would be to perform the function point count only after the project is completed.

]]>