planning poker question

[dotnetguy]

Hello - How do you describe a 1 to the team for planning poker? Can 1 be appropriately described as "the most straightforward and basic story with no constraints"? An example of this might be setting a known appsetting to a known value in Web.config. This baseline seems to be appropriate since other factors like unknowns, dependencies and delays should increase the relative size of a story.

Also, 1/2 is included in some planning poker card decks. 1/2 doesn't seem very useful to me if 1 is defined as the most basic, straightforward story. Also, 1/2 point for a story doesn't seem very realistic with the set of requirements that a story must typically meet in order to satisfy the team's DoD. What are your thoughts?

[George Dinwiddie]

Andrew,

On 1/6/13 8:45 PM, dotnetguy wrote:
> Hello - How do you describe a 1 to the team for planning poker? Can
> 1 be appropriately described as "the most straightforward and basic
> story with no constraints"? An example of this might be setting a
> known appsetting to a known value in Web.config. This baseline seems
> to be appropriate since other factors like unknowns, dependencies and
> delays should increase the relative size of a story.

It doesn't much matter. After the first sprint, a 1 is whatever is
similar in size to what was called a 1 in the previous sprint.

> Also, 1/2 is included in some planning poker card decks. 1/2 doesn't
> seem very useful to me if 1 is defined as the most basic,
> straightforward story. Also, 1/2 point for a story doesn't seem very
> realistic with the set of requirements that a story must typically
> meet in order to satisfy the team's DoD. What are your thoughts?

I think you're over-thinking it. The half point estimate works well for
teams that have learned to slice stories thinner than what they call a
1. Unless your definition of done involves paperwork and/or ceremonies,
it shouldn't affect your estimates.

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[Rafael Sabbagh]

Hi Andrew,

are you talking about Story Points?

If so, it is a relative scale. It's not absolute, so "1" alone doesn't mean anything.

The Dev Team will define this scale by, for example, assigning "2" to the smallest item they have at the Product Backlog, at the beginning of the project (or whenever they decide to start estimating). This is just one technique. If that's the technique the team used, "1" would mean roughly half of "2", i.e. half of the base item. If that's not the technique the team used, how did the Dev Team define the scale?

Anyway, do you really need to estimate? :)


Best regards,

Rafael Sabbagh
Agile Trainer & Coach
Certified Scrum Trainer (CST)
________________________
Sabbagh Training & Coaching
Rio de Janeiro - Brazil
+55 (21) 9999-7895
http://rsabbagh.com
http://facebook.com/SabbaghTC
@rsabbagh

On Sun, Jan 6, 2013 at 11:45 PM, dotnetguy <andrew.d....@gmail.com> wrote:

Hello - How do you describe a 1 to the team for planning poker?  Can 1 be appropriately described as "the most straightforward and basic story with no constraints"?  An example of this might be setting a known appsetting to a known value in Web.config.  This baseline seems to be appropriate since other factors like unknowns, dependencies and delays should increase the relative size of a story.

Also, 1/2 is included in some planning poker card decks.  1/2 doesn't seem very useful to me if 1 is defined as the most basic, straightforward story.  Also, 1/2 point for a story doesn't seem very realistic with the set of requirements that a story must typically meet in order to satisfy the team's DoD.  What are your thoughts?

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To view this discussion on the web visit https://groups.google.com/d/msg/scrumalliance/-/QGbtOpn6Kf8J.
To post to this group, send email to scruma...@googlegroups.com.
To unsubscribe from this group, send email to scrumallianc...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scrumalliance?hl=en.

[Mark Levison]

Most teams start with a prototypical '2'. I suggest a '2' be small enough that you could hey 5-10 similar sized stories completed in one sprint.

Cheers
Mark

On Jan 7, 2013 1:45 AM, "dotnetguy" <andrew.d....@gmail.com> wrote:

Hello - How do you describe a 1 to the team for planning poker?  Can 1 be appropriately described as "the most straightforward and basic story with no constraints"?  An example of this might be setting a known appsetting to a known value in Web.config.  This baseline seems to be appropriate since other factors like unknowns, dependencies and delays should increase the relative size of a story.

Also, 1/2 is included in some planning poker card decks.  1/2 doesn't seem very useful to me if 1 is defined as the most basic, straightforward story.  Also, 1/2 point for a story doesn't seem very realistic with the set of requirements that a story must typically meet in order to satisfy the team's DoD.  What are your thoughts?

[dotnetguy]

@mark - I think if 1 is defined as "the most basic straightforward story with no constraints" then this compliments and can be used in conjunction with your idea of the team identifying a current story with a "prototypical 2."

This is because in reality most stories will not be "the most basic straightforward story with no constraints." It will be much easier for the team to identify a story that's twice as big as an ideal story point.

[Mark Levison]

dotnetguy wrote:

@mark - I think if 1 is defined as "the most basic straightforward story with no constraints" then this compliments and can be used in conjunction with your idea of the team identifying a current story with a "prototypical 2."

This is because in reality most stories will not be "the most basic straightforward story with no constraints."  It will be much easier for the team to identify a story that's twice as big as an ideal story point.

Perhaps I've never met an ideal story point, I don't worry about them much.

Cheers
Mark Levison
Agile Pain Relief Consulting | Writing
Proud Sponsor of Agile Tour Gatineau Ottawa Nov 28, Toronto 26 and Montreal 24

[dotnetguy]

@Mark - I think updating a known appsetting to a known value in Web.config would be a good example of 1 ideal story point. This would also provide a meaningful context for sizing to help avoid oversimplifying and undersizing other stories.

[Mark Levison]

On Sun, Jan 6, 2013 at 7:22 PM, dotnetguy <andrew.d....@gmail.com> wrote:

@Mark - I think updating a known appsetting to a known value in Web.config would be a good example of 1 ideal story point.  This would also provide a meaningful context for sizing to help avoid oversimplifying and undersizing other stories.

For you this maybe true. Perhaps even for your team however we've not heard from them yet. For other teams this maybe 1/2 or even 0 (i.e. too small to notice), for a new team straight out school this might be a 5. Its all relative to your team.

Cheers

Mark 

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.

To view this discussion on the web visit https://groups.google.com/d/msg/scrumalliance/-/YsI-bUjAjfcJ.

To post to this group, send email to scruma...@googlegroups.com.
To unsubscribe from this group, send email to scrumallianc...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scrumalliance?hl=en.

--

[Yves Hanoulle]

Just as Mark ( I think) I prefer that the basic story is set to two
wen we start.
Why?
Because by the time the get used to it, they learn that they can do
smaller stories.
You say that setting a web config setting is the smallest thing , well
that depends: I know companies where updating a config setting and
deploying that to production involves 10 ( yes ten) people.
This is why people like Mark and George say: it depends. We can't set
hard rules for your teams.
It looks like you are right. And yes in a year (or less time) your
team will be able to create smaller stories that still bring lots of
value to your customers

Scrambled by my Yphone

Op 7-jan.-2013 om 02:45 heeft dotnetguy
<andrew.d....@gmail.com> het volgende geschreven:

> Hello - How do you describe a 1 to the team for planning poker? Can 1 be appropriately described as "the most straightforward and basic story with no constraints"? An example of this might be setting a known appsetting to a known value in Web.config. This baseline seems to be appropriate since other factors like unknowns, dependencies and delays should increase the relative size of a story.
>
> Also, 1/2 is included in some planning poker card decks. 1/2 doesn't seem very useful to me if 1 is defined as the most basic, straightforward story. Also, 1/2 point for a story doesn't seem very realistic with the set of requirements that a story must typically meet in order to satisfy the team's DoD. What are your thoughts?
>

> --
> You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.

> To view this discussion on the web visit https://groups.google.com/d/msg/scrumalliance/-/QGbtOpn6Kf8J.

[Ron Jeffries]

Andrew,

On Jan 6, 2013, at 10:22 PM, dotnetguy <andrew.d....@gmail.com> wrote:

@Mark - I think updating a known appsetting to a known value in Web.config would be a good example of 1 ideal story point.  This would also provide a meaningful context for sizing to help avoid oversimplifying and undersizing other stories.

It turns out that selecting the smallest possible story size and scaling from there is probably the least accurate thing one could do. Selecting one or more well-understood middle-sized stories  to be 5s or 8s will work better.

It turns out that oversimplifying and undersizing are not corrected by better estimation, and certainly not by using some trivial change as the baseline. Oversimplifying and undersizing are in large part the result of failure to understand the story, not failure to have some standard to compare to. They are also, in large part, due to failure to properly simplify the feature and compress all the fat out of it.

It turns out that estimation accuracy is one of the least valuable skills a team can have, and focus on it is evidence that the organization is not yet applying Scrum anywhere nearly as well as it could. The reason for this is that Scrum works best when the Product Owner is not just doling out work and the team isn't just estimating it with everyone figuring out when they'll be done. Scrum done well is about the whole team looking at the work needed and creatively building something that maximizes value and minimizes work. 

It turns out that the main point of estimation is to decide how much work to take on in the Sprint, and the team will learn to do that on their own. Quite often, the main problem they have in doing that is conscious or unconscious pressure to "do more".

I'm thinking I'd advise less thinking, more doing.

Ron Jeffries

www.XProgramming.com

There's no word for accountability in Finnish. 

Accountability is something that is left when responsibility has been subtracted. 

--Pasi Sahlberg

[Woody Zuill]

To me, the main value of story point estimating is as a tool for a team to learn how to break things down into "sprint size" pieces.  As a team becomes skilled at breaking stories into smaller (yet still deliverable) pieces, the less need they have for using planning poker. Once the ability to "chip off a small, doable, deliverable chunk" becomes easy for the team, the work flow changes a bit.  The team no longer needs planning poker - they simply choose important stuff, break off a few valuable, small pieces to work on, and goes to work doing them.  Over and over again.

 

One approach that has worked for me in finding a way to size things is to do it during the spring planning session: Lay out all the stories in "size order" on the table - No numbers, just "Is this bigger or smaller (or the same) as that.  Once you have them laid out you can group them into the numbering system you use.  The group of the small items becomes 1, next group 2, and so on.  During the Sprint you will get a feel for if the 2's were more or less double the 1's, and so on.  "More or less" is fine - you don't need precision.

This doesn't really answer your question: "How do you describe a 1 to the team for planning poker?" - but it replaces it with a way to work with the numbers. In the past when I used story points and planning poker, I found that the important thing is that a 1 is the smallest thing that we can do discretely that brings value once built and delivered. Smaller than 1 has been a place to put things that are tiny, but not really stories.  We would mark something as zero if we felt something would "come for free" in the doing of another story.  Also, anything bigger than a 5 was put into a bucket of "Too big, must break down before we put any work on it".  For me, usually 1 & 2 are considered for taking on as work, 3 & 5 need to be sliced up if at all possible, 8+ it "Too Big". 

 

 

 

 

 

 

[Michael James]

I just stumbled on this 4 year old thread and thought Woody’s answer was worth re-posting.

—mj

(Michael)

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.

To view this discussion on the web visit https://groups.google.com/d/msg/scrumalliance/-/VvWO_rGElh0J.