I read a question posted on the Scrum Alliance Google Group, and jotted down a few thoughts about Planning Card Games.<\/p>\n
How do you describe a 1 to the team for Planning Poker\u00ae?<\/p>\n
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.\u00a0 As a team becomes skilled at breaking stories into smaller (yet still valuable and deliverable) pieces, the less need they have for using estimating games. Once the ability to “chip off a small, do-able, deliverable chunk” becomes easy for the team, the work flow changes a bit.\u00a0 The team no longer needs estimating games – they simply choose important stuff, break off a few valuable, small pieces to work on, and\u00a0then do the\u00a0work and build\/deploy.\u00a0 Over and over again.<\/p>\n
Many don’t see it that way, and\u00a0use estimating games to make decisions about what work to bring into a Sprint. That is a legitimate use in some workplaces,\u00a0and whatever works for you is the right thing.\u00a0 For me, the scheduling of work for a Sprint is not nearly as important as breaking work into a “do-able” condition, and getting it done.\u00a0 I’m interested in\u00a0choosing what we work on based on\u00a0the\u00a0value to the “customer”,\u00a0 not how big things are.\u00a0 We can only do so much work at a time. \u00a0Finding valuable things to work on is where I put my focus.<\/p>\n
One approach that has worked for me in finding a way to size things is to do it during the first Sprint Planning Session:
\nTake all the Stories you are considering, and lay\u00a0them out\u00a0in “size order” on the table – No numbers, just “Is this bigger or smaller (or the same) as that”.\u00a0 Once you have them laid out you can group them into the numbering system you use.\u00a0 The group of the small items becomes 1, next group 2, and so on.\u00a0 During the Sprint you will get a feel for if the 2’s were more or less double the 1’s, and so on.\u00a0 “More or less” is fine – you don’t need precision.\u00a0 You are just “getting a feel for it” anyway.<\/p>\n
Over time, the team will be able to quickly gauge a basic size for each story – with the main goal being to find the ones that need to be broken down further so they can be taken on as work.\u00a0 Once a story is taken on as work, you’ll discover the real nature of the story and it’s “size” – it is often found that it needs to be broken up into a few smaller chunks.<\/p>\n
This doesn’t really answer your question: “How do you describe a 1 to the team for Planning Poker\u00ae?” – but it replaces it with a way to work with the numbers. In the past when I used story points and planning cards, I found this to be the definition that worked for me:\u00a0\u00a0The “1” story point\u00a0is the smallest thing that we can do discretely that brings value once built and delivered.\u00a0 Smaller than 1 is the\u00a0place to put things that are tiny, but not really stories.\u00a0 We would mark something as zero if we felt it would “come for free” in the doing of another story.\u00a0 Also, anything bigger than a 5 was put into a bucket of “Too big, must break down before we put any work on it”.\u00a0 For me, usually 1 & 2 are considered for taking on as work, 3 & 5 need to be sliced up if at all possible (and if it can’t be easily sliced up\u00a0it’s a signal that\u00a0we need to learn how to better define and break up a story),\u00a0 and 8+ is “Too Big – must be sliced up”.<\/p>\n
Note:\u00a0Planning Poker\u00ae is a registered trademark of Mountain Goat Software, LLC.<\/p>\n","protected":false},"excerpt":{"rendered":"
I read a question posted on the Scrum Alliance Google Group, and jotted down a few thoughts about Planning Card Games. The Basic Question Being Asked: How do you describe a 1 to the team for Planning Poker\u00ae? The value of Estimating using Card Games: To me, the main value of story point estimating is […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-375","post","type-post","status-publish","format-standard","hentry","category-agile-stuff"],"_links":{"self":[{"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/posts\/375","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/comments?post=375"}],"version-history":[{"count":19,"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/posts\/375\/revisions"}],"predecessor-version":[{"id":386,"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/posts\/375\/revisions\/386"}],"wp:attachment":[{"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/media?parent=375"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/categories?post=375"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/tags?post=375"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}