{"id":491,"date":"2011-05-10T07:04:58","date_gmt":"2011-05-10T07:04:58","guid":{"rendered":"http:\/\/mikekuphal.azurewebsites.net\/?p=491"},"modified":"2011-05-10T07:04:58","modified_gmt":"2011-05-10T07:04:58","slug":"agile-planning-ideal-day-user-story-estimation","status":"publish","type":"post","link":"https:\/\/mikekuphal.com\/?p=491","title":{"rendered":"Agile Planning: ‘Ideal Day’ – User Story Estimation"},"content":{"rendered":"

\"US\"<\/a>I don\u2019t like Story Point estimating<\/a>.\u00a0 There I said it.\u00a0 I know many have had success with Story Point estimating, and the Scrum guru Mike Cohn<\/a> advocates it in his books\/etc.\u00a0 I have just found it to be too abstract, and difficult for developers (and myself) to grasp when starting out using Agile techniques.<\/p>\n

In my experience, when developers\/engineers\/etc. are asked to estimate in hours (which is very much the norm in software), they \"rulers\"<\/a>aren\u2019t really thinking in hours.\u00a0 Truth be told, I don\u2019t think many actually think in hour blocks when estimating, but instead think in terms of \u2018days of work\u2019 or partial days of work.\u00a0 Here\u2019s an example of what a developer is thinking when giving an estimate:\u00a0 \u201cHmm.. I think this task should take me about a day, maybe day and half to complete, so lets make it 8*1.5 = 12 hours\u201d\u00a0 Tell me you don\u2019t do that?\u00a0 There wasn\u2019t any self talk on thinking part one of the task would take 2 hours, part two, 6 hours, etc. but rather they would \u2018chunk\u2019 their time into days.<\/p>\n

So in comes Story point estimating.\u00a0 We don\u2019t want to be estimating User Stories<\/a> from a calendar time perspective, but instead relatively against each other.\u00a0 This allows for quick estimates that give size, but not \u2018commitment\u2019 to time which is what most developers feel an estimate is. Hour estimates come during User Story<\/a> decomposition, part of Sprint planning.\u00a0 Unfortunately, how do you define one Story Point?\u00a0 What is your logical point of reference?<\/p>\n

This is where the \u2018Ideal Day\u2019 metric works better for me.\u00a0 This metric was shared with me by Pete Carroll<\/a> and is really an abstraction of the number of hours you would normally expect a developer to be productive during a typical day, subtracting time for meetings, bathroom breaks, etc. This will vary from organization to organization, but has a large benefit over Story Point Estimation IMHO.\u00a0 Mainly it is the default metric the developers are already thinking in as I eluded to above.\u00a0 There isn\u2019t any translation in their head, no trying to define an ambiguous metric.\u00a0 Instead it\u2019s more gut feel that is natural to all developers with some experience while still allowing for the relative estimating of User Stories to take place. All Ideal Day estimates should be in round numbers, (ie 1,2,3. not 1.5, 2.34, etc).<\/p>\n

Trick here is to realize the Ideal Day metric is still an abstraction of time estimates.\u00a0 We don\u2019t plan off the Ideal Day on a timeline, but instead use team velocity matched with Ideal Days to equate to time-lining User Stories from a high level.\u00a0 The Velocity<\/a> metric will help even out the group estimation variance just like with Story points, but it feels so much more natural to the team.<\/p>\n

Next up in this series, decomposing user story tips<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"

I don\u2019t like Story Point estimating.\u00a0 There I said it.\u00a0 I know many have had success with Story Point estimating, and the Scrum guru Mike Cohn advocates it in his books\/etc.\u00a0 I have just found it to be too abstract, and difficult for developers (and myself) to grasp when starting out using Agile techniques. In … Continue reading “Agile Planning: ‘Ideal Day’ – User Story Estimation”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2,4],"tags":[],"class_list":["post-491","post","type-post","status-publish","format-standard","hentry","category-agile","category-mobileconnections"],"_links":{"self":[{"href":"https:\/\/mikekuphal.com\/index.php?rest_route=\/wp\/v2\/posts\/491","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mikekuphal.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mikekuphal.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mikekuphal.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mikekuphal.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=491"}],"version-history":[{"count":0,"href":"https:\/\/mikekuphal.com\/index.php?rest_route=\/wp\/v2\/posts\/491\/revisions"}],"wp:attachment":[{"href":"https:\/\/mikekuphal.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=491"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mikekuphal.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=491"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mikekuphal.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=491"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}