Story Points Estimation - Revision history

Tkokotas at 15:39, 18 December 2018

2018-12-18T15:39:58Z

← Older revision		Revision as of 15:39, 18 December 2018
Line 1:		Line 1:
	~~[[Category:Complexity]] [[Category:Tool]] [[Category:Agile Project Management]]~~		''Developed by Ian Thobias Jacobsen''


	'''A Story Point''' is an estimation metric used by many IT-development teams. Story Points are often recommended in [[Agile Project Management]] frameworks and methods such as [[Scrum]], Agile-Kanban or Extreme Programming (XP).		'''A Story Point''' is an estimation metric used by many IT-development teams. Story Points are often recommended in [[Agile Project Management]] frameworks and methods such as [[Scrum]], Agile-Kanban or Extreme Programming (XP).
	The Story Point estimation tool separates itself from conventional tools by being an arbitrary unit of measure that estimates '''required effort''' instead of the more tangible and well-known '''Hours'''. Proponents of the tool argues that Story Points encompass a range of dimensions including, complexity, uncertainty and risks involved with the completion of the estimated task. It remains, however, a controversial tool, often because the concept is not well understood; the benefits are abstract and effective use requires prerequisite work as well as medium or long project run-times.		The Story Point estimation tool separates itself from conventional tools by being an arbitrary unit of measure that estimates '''required effort''' instead of the more tangible and well-known '''Hours'''. Proponents of the tool argues that Story Points encompass a range of dimensions including, complexity, uncertainty and risks involved with the completion of the estimated task. It remains, however, a controversial tool, often because the concept is not well understood; the benefits are abstract and effective use requires prerequisite work as well as medium or long project run-times.
Line 156:		Line 158:
	= References =		= References =
	<references />		<references />
			[[Category:Complexity]] [[Category:Tool]] [[Category:Agile Project Management]]

S113735: /* Annotated Bibliography */

2015-09-27T21:52:31Z

Annotated Bibliography

← Older revision		Revision as of 21:52, 27 September 2015
Line 141:		Line 141:

	Cohn, Mike (2007) [https://www.mountaingoatsoftware.com/blog/why-i-dont-use-story-points-for-sprint-planning ''Why I Don't Use Story Points For Sprint Planning''] and Cheng, Chai Wei (2012) [https://www.scrumalliance.org/community/articles/2012/august/story-points-versus-task-hours ''Story Points Versus Task Hours'']		Cohn, Mike (2007) [https://www.mountaingoatsoftware.com/blog/why-i-dont-use-story-points-for-sprint-planning ''Why I Don't Use Story Points For Sprint Planning''] and Cheng, Chai Wei (2012) [https://www.scrumalliance.org/community/articles/2012/august/story-points-versus-task-hours ''Story Points Versus Task Hours'']
	:::These two articles independently argue the drawbacks of using Story Points for Sprint planning. The two authors reach the same conclusion, that Story Points finds merits mostly in their ability to easily estimate and measure velocity as a ''high-level'' measuring tool while, in fact, Hours in many cases are a better fit when planning sprints. Both authors argue that the quite fluctuating velocity of Agile teams makes it too hard to estimate ''to capacity'' in Agile Sprints.		:::These two articles independently argue the drawbacks of using Story Points for Sprint planning. The two authors reach the same conclusion; that Story Points finds merits mostly in their ability to easily estimate and measure velocity as a ''high-level'' measuring tool while, in fact, Hours in many cases are a better fit when planning sprints. Both authors argue that the quite fluctuating velocity of Agile teams makes it too hard to estimate ''to capacity'' in Agile Sprints.

	Radigan, Dan [https://www.atlassian.com/agile/estimation ''Agile Estimation''], Atlassian web-page		Radigan, Dan [https://www.atlassian.com/agile/estimation ''Agile Estimation''], Atlassian web-page
Line 149:		Line 149:

	Georgsson, Anna (2011) [http://www.diva-portal.org/smash/get/diva2:400313/FULLTEXT01.pdf ''A Case Study at Swedbank IT'']		Georgsson, Anna (2011) [http://www.diva-portal.org/smash/get/diva2:400313/FULLTEXT01.pdf ''A Case Study at Swedbank IT'']
	:::This interview-based study of a department at Swedbank IT thoroughly examines various Agile tools and practices with a special focus on Story Points and improving Estimation certainty. The case-study is yet another example of Scrum implementation and core findings include improved task understanding and decreased unnecessary work. The Master Thesis provides a well-referenced list of advantages of Scrum-practices and tools.		:::This interview-based study of a department at Swedbank IT thoroughly examines various Agile tools and practices with a special focus on Story Points and improving Estimation certainty. The case-study is yet another example of Scrum implementation and core findings include improved task understanding and decreased unnecessary work. The Master Thesis also provides a well-referenced list of advantages of Scrum-practices and tools.

	Williams, Laurie. [http://collaboration.csc.ncsu.edu/laurie/Papers/ESEM11_SCRUM_Experience_CameraReady.pdf ''Scrum Practices: Experiences of Three Microsoft Teams'']		Williams, Laurie. [http://collaboration.csc.ncsu.edu/laurie/Papers/ESEM11_SCRUM_Experience_CameraReady.pdf ''Scrum Practices: Experiences of Three Microsoft Teams'']
	:::This case-study research is based on ~~the~~ empirical data from three Microsoft development teams that has transitioned to Agile Project Management and a Story Point estimation-practice. The study gives a brief introduction to the Scrum framework and various Agile tools and practices applied by the three teams. Core findings include a drop of efficiency the first 3 iterations of the implementation followed by a significant improvement in productivity without having a cost on quality. Another core finding is the merit of implementing a "Planning Poker"-practice. Recommended reading for anyone doubting the eligibility, purpose or implementation of Scrum.		:::This case-study research is based on empirical data from three Microsoft development teams that has transitioned to Agile Project Management and a Story Point estimation-practice. The study gives a brief introduction to the Scrum framework and various Agile tools and practices applied by the three teams. Core findings include a drop of efficiency the first 3 iterations of the implementation followed by a significant improvement in productivity without having a cost on quality. Another core finding is the merit of implementing a "Planning Poker"-practice. Recommended reading for anyone doubting the eligibility, purpose or implementation of Scrum.

	= References =		= References =
	<references />		<references />

S113735: /* Mixed Approach */

2015-09-27T21:51:23Z

Mixed Approach

← Older revision		Revision as of 21:51, 27 September 2015
Line 120:		Line 120:

	== Mixed Approach ==		== Mixed Approach ==
	'''Mixing hours and Story Points''' is '''not a recommended practice'''. This is because hours and Story Points don't measure the same thing. There exist no good trade-off metrics as a Story Point might pertain to 8.3 Hours of work one week, 4 Hours the next and 7.2 Hours the week after that. That being said, the practice is not unheard of:		'''Mixing hours and Story Points''' is '''not a recommended practice'''. This is because hours and Story Points don't measure the same thing. There exist no good trade-off metrics as a Story Point might pertain to 8.3 Hours of work one week, 4 Hours the next and 7.2 Hours the week after that. That being said, the practice is not unheard of and can be used with some benefits in informed project teams:

	Story Points are, as elaborated, a relative measure good for long-term estimation and progress-tracking. But it ~~may lack~~ some short-term benefits.		Story Points are, as elaborated, a relative measure good for long-term estimation and progress-tracking. But it lacks some short-term benefits.
	In the referenced examples<ref> Cohn, Mike (2007) [https://www.mountaingoatsoftware.com/blog/why-i-dont-use-story-points-for-sprint-planning ''Why I Don't Use Story Points For Sprint Planning'']</ref><ref> Cheng, Chai Wei (2012) [https://www.scrumalliance.org/community/articles/2012/august/story-points-versus-task-hours ''Story Points Versus Task Hours'']</ref>(see also '''Annotated Bibliography'''), two teams have decided to use Story Points as a ''high level measure'', while using hours as a ''low level measure'' for Sprint-planning. In both examples it is argued that Hours give a better chance of committing "to capacity" for a sprint so that you don't end up having idle developers towards the end of an iteration.		In the referenced examples<ref> Cohn, Mike (2007) [https://www.mountaingoatsoftware.com/blog/why-i-dont-use-story-points-for-sprint-planning ''Why I Don't Use Story Points For Sprint Planning'']</ref><ref> Cheng, Chai Wei (2012) [https://www.scrumalliance.org/community/articles/2012/august/story-points-versus-task-hours ''Story Points Versus Task Hours'']</ref>(see also '''Annotated Bibliography'''), two teams have decided to use Story Points as a ''high level measure'', while using hours as a ''low level measure'' specifically for Sprint-planning. In both examples, it is argued that Hours give a better chance of committing "to capacity" for a sprint so that you don't end up having idle developers towards the end of an iteration.

	= Annotated Bibliography =		= Annotated Bibliography =

S113735: /* Hours */

2015-09-27T21:49:16Z

Hours

← Older revision		Revision as of 21:49, 27 September 2015
Line 107:		Line 107:
	#*See also the [http://apppm.man.dtu.dk/index.php/Program_evaluation_and_review_technique_(PERT)#Estimation_of_the_time PERT Article] from the Wiki.		#*See also the [http://apppm.man.dtu.dk/index.php/Program_evaluation_and_review_technique_(PERT)#Estimation_of_the_time PERT Article] from the Wiki.
	# Revisit estimates often.		# Revisit estimates often.
	#*Once the project ~~progresses~~, review hourly estimates often using the new knowledge you've acquired. This will help keep track on the ~~future~~ delivery date.		#*Once the project start progressing, review hourly estimates often using the new knowledge you've acquired. This will help keep track on the delivery date.
	#*This is generally also a good idea when estimating using Story Points. Completion of some tasks, especially in IT projects, may positively influence the remaining work in another, unrelated task.		#*This is generally also a good idea when estimating using Story Points. Completion of some tasks, especially in IT projects, may positively influence the remaining work in another (seemingly) unrelated task.
	#*This is because possible code-redundancy becomes more apparent when some tasks have already been developed.		#*This is because possible code-redundancy becomes more apparent when some tasks have already been developed.
	# Remember estimation uncertainty is often [https://en.wikipedia.org/wiki/Log-normal_distribution log-normally distributed] (citation needed).		# Remember estimation uncertainty is often [https://en.wikipedia.org/wiki/Log-normal_distribution log-normally distributed] (citation needed).
	#*This has the implication that estimates are often ''skewed to the right''<ref> https://en.wikipedia.org/wiki/Log-normal_distribution Reliawiki </ref>.		#*This has the implication that estimates are often ''skewed to the right''<ref> https://en.wikipedia.org/wiki/Log-normal_distribution Reliawiki </ref>.
	#*This simply means that ~~estimations~~ generally are overly optimistic with a larger portion of estimates being lower than reality. Use this when developing your estimation formula.		#*This simply means that estimators generally are overly optimistic, with a larger portion of estimates being lower/promising faster delivery than reality. Use this knowledge when developing your estimation formula.
	# Compare and share your estimates with stakeholders and other developers.		# Compare and share your estimates with stakeholders and other developers.
	#*Teams are much better at estimating than individuals<ref> Radigan, Dan [https://www.atlassian.com/agile/estimation Atlassian ''Agile Estimation''], Atlassian </ref>. Agile development also emphasize that estimation is a ''Team Sport''.		#*Teams are much better at estimating than individuals<ref> Radigan, Dan [https://www.atlassian.com/agile/estimation Atlassian ''Agile Estimation''], Atlassian </ref>. Agile development also emphasize that estimation is a ''Team Sport''.
	#*Don't be afraid to ~~tell~~ the product owner your real ~~hourly~~ estimate for a task~~; maybe the healthy~~ discussion ~~will align some~~ expectations ~~or clear~~ up ~~some~~ miscommunication ~~or documentation~~.		#*Don't be afraid to inform the product owner, project manager and team members of your real/expected estimate for a task (i.e. don't try to impress anyone with how fast you think you can implement a task when estimating): Healthy discussion aligns expectations, clears up miscommunication and reduces work redundancy.

	For further reading on human uncertainty see the Wiki: [[Mindfulness and Cognitive Biases in Project Management]].		For further reading on human uncertainty see the Wiki: [[Mindfulness and Cognitive Biases in Project Management]].

S113735: /* Ideal Days */

2015-09-27T21:42:00Z

Ideal Days

← Older revision		Revision as of 21:42, 27 September 2015
Line 94:		Line 94:
	Although it doesn't necessarily fit with the Fibonacci sequence (as proposed in Step 2 of the [http://apppm.man.dtu.dk/index.php/Story_Points_Estimation#Application_and_Use example guideline above]) the team will still be able to commit a certain number of point to each sprint, measure velocity, get an idea of current overhead, break down large tasks into smaller etc. just like when using the Story Point estimation tool.		Although it doesn't necessarily fit with the Fibonacci sequence (as proposed in Step 2 of the [http://apppm.man.dtu.dk/index.php/Story_Points_Estimation#Application_and_Use example guideline above]) the team will still be able to commit a certain number of point to each sprint, measure velocity, get an idea of current overhead, break down large tasks into smaller etc. just like when using the Story Point estimation tool.
	A story thought to last one Ideal Day typically takes a lot longer to implement than one work day. This is because the tool doesn't take into consideration interruptions such as meetings or unexpected problems such as computer-failure i.a.		A story thought to last one Ideal Day typically takes a lot longer to implement than one work day. This is because the tool doesn't take into consideration interruptions such as meetings or unexpected problems such as computer-failure i.a.
	The team should take special care when estimating Ideal Days, unlike Story Points, that takes input from the whole team, Ideal Days may vary greatly between developers; a task that would take one developer half a day might take another two days to implement. People not only have different schedules that might affect their "Ideal Day to Work Day"-ratio, but also have different skill levels to take into consideration.		The team should take special care when estimating Ideal Days, unlike Story Points, that takes input from the whole team, Ideal Days may vary greatly between developers; a task that would take one developer half a day might take another two days to implement. People not only have different schedules that might affect their "Ideal Day to Work Day"-ratio, but often also have different skill levels to take into consideration.

	== Hours ==		== Hours ==

S113735: /* Ideal Days */

2015-09-27T21:41:03Z

Ideal Days

← Older revision		Revision as of 21:41, 27 September 2015
Line 94:		Line 94:
	Although it doesn't necessarily fit with the Fibonacci sequence (as proposed in Step 2 of the [http://apppm.man.dtu.dk/index.php/Story_Points_Estimation#Application_and_Use example guideline above]) the team will still be able to commit a certain number of point to each sprint, measure velocity, get an idea of current overhead, break down large tasks into smaller etc. just like when using the Story Point estimation tool.		Although it doesn't necessarily fit with the Fibonacci sequence (as proposed in Step 2 of the [http://apppm.man.dtu.dk/index.php/Story_Points_Estimation#Application_and_Use example guideline above]) the team will still be able to commit a certain number of point to each sprint, measure velocity, get an idea of current overhead, break down large tasks into smaller etc. just like when using the Story Point estimation tool.
	A story thought to last one Ideal Day typically takes a lot longer to implement than one work day. This is because the tool doesn't take into consideration interruptions such as meetings or unexpected problems such as computer-failure i.a.		A story thought to last one Ideal Day typically takes a lot longer to implement than one work day. This is because the tool doesn't take into consideration interruptions such as meetings or unexpected problems such as computer-failure i.a.
	The team should take special care when estimating Ideal Days, unlike Story Points, that takes input from the whole team, Ideal Days may vary greatly between developers; a task that would take one developer half a day might take another 2 days to implement. People not only have different schedules that might affect ~~the number of~~ Ideal ~~Days~~, but also ~~has~~ different skill levels to take into consideration.		The team should take special care when estimating Ideal Days, unlike Story Points, that takes input from the whole team, Ideal Days may vary greatly between developers; a task that would take one developer half a day might take another two days to implement. People not only have different schedules that might affect their "Ideal Day to Work Day"-ratio, but also have different skill levels to take into consideration.

	== Hours ==		== Hours ==

S113735: /* Ideal Days */

2015-09-27T21:39:20Z

Ideal Days

← Older revision		Revision as of 21:39, 27 September 2015
Line 92:		Line 92:
	''"Imagine a team estimating using Ideal Days having a backlog of tasks requiring 0.5 day, 1 day, 2 days etc. Now, convert each of these estimations into Story Points using a 1:1 scale: 0.5 Ideal Days = 0.5 Story Points, 1 Ideal Day = 1 Story Point and so on..."''		''"Imagine a team estimating using Ideal Days having a backlog of tasks requiring 0.5 day, 1 day, 2 days etc. Now, convert each of these estimations into Story Points using a 1:1 scale: 0.5 Ideal Days = 0.5 Story Points, 1 Ideal Day = 1 Story Point and so on..."''

	Although it doesn't necessarily fit with the Fibonacci sequence (as proposed in the [http://apppm.man.dtu.dk/index.php/Story_Points_Estimation#Application_and_Use example guideline above]) the team will still be able to commit a certain number of point to each sprint, measure velocity, get an idea of current overhead, break down large tasks into smaller etc. just like when using the Story Point estimation tool.		Although it doesn't necessarily fit with the Fibonacci sequence (as proposed in Step 2 of the [http://apppm.man.dtu.dk/index.php/Story_Points_Estimation#Application_and_Use example guideline above]) the team will still be able to commit a certain number of point to each sprint, measure velocity, get an idea of current overhead, break down large tasks into smaller etc. just like when using the Story Point estimation tool.
	A story thought to last one Ideal Day typically takes a lot longer to implement than one work day. This is because the tool doesn't take into consideration interruptions such as meetings or unexpected problems such as computer-failure i.a.		A story thought to last one Ideal Day typically takes a lot longer to implement than one work day. This is because the tool doesn't take into consideration interruptions such as meetings or unexpected problems such as computer-failure i.a.
	The team should take special care when estimating Ideal Days, unlike Story Points, that takes input from the whole team, Ideal Days may vary greatly between developers; a task that would take one developer half a day might take another 2 days to implement. People not only have different schedules that might affect the number of Ideal Days, but also has different skill levels to take into consideration.		The team should take special care when estimating Ideal Days, unlike Story Points, that takes input from the whole team, Ideal Days may vary greatly between developers; a task that would take one developer half a day might take another 2 days to implement. People not only have different schedules that might affect the number of Ideal Days, but also has different skill levels to take into consideration.

S113735: /* Ideal Days */

2015-09-27T21:38:52Z

Ideal Days

← Older revision		Revision as of 21:38, 27 September 2015
Line 92:		Line 92:
	''"Imagine a team estimating using Ideal Days having a backlog of tasks requiring 0.5 day, 1 day, 2 days etc. Now, convert each of these estimations into Story Points using a 1:1 scale: 0.5 Ideal Days = 0.5 Story Points, 1 Ideal Day = 1 Story Point and so on..."''		''"Imagine a team estimating using Ideal Days having a backlog of tasks requiring 0.5 day, 1 day, 2 days etc. Now, convert each of these estimations into Story Points using a 1:1 scale: 0.5 Ideal Days = 0.5 Story Points, 1 Ideal Day = 1 Story Point and so on..."''

	Although it doesn't necessarily fit with the Fibonacci sequence (as proposed in the example guideline above) the team will still be able to commit a certain number of point to each sprint, measure velocity, get an idea of current overhead, break down large tasks into smaller etc. just like when using the Story Point estimation tool.		Although it doesn't necessarily fit with the Fibonacci sequence (as proposed in the [http://apppm.man.dtu.dk/index.php/Story_Points_Estimation#Application_and_Use example guideline above]) the team will still be able to commit a certain number of point to each sprint, measure velocity, get an idea of current overhead, break down large tasks into smaller etc. just like when using the Story Point estimation tool.
	A story thought to last one Ideal Day typically takes a lot longer to implement than one work day. This is because the tool doesn't take into consideration interruptions such as meetings or unexpected problems such as computer-failure i.a.		A story thought to last one Ideal Day typically takes a lot longer to implement than one work day. This is because the tool doesn't take into consideration interruptions such as meetings or unexpected problems such as computer-failure i.a.
	The team should take special care when estimating Ideal Days, unlike Story Points, that takes input from the whole team, Ideal Days may vary greatly between developers; a task that would take one developer half a day might take another 2 days to implement. People not only have different schedules that might affect the number of Ideal Days, but also has different skill levels to take into consideration.		The team should take special care when estimating Ideal Days, unlike Story Points, that takes input from the whole team, Ideal Days may vary greatly between developers; a task that would take one developer half a day might take another 2 days to implement. People not only have different schedules that might affect the number of Ideal Days, but also has different skill levels to take into consideration.

S113735: /* Ideal Days */

2015-09-27T21:37:17Z

Ideal Days

← Older revision		Revision as of 21:37, 27 September 2015
Line 90:		Line 90:
	'''With Ideal Days''' you apply an absolute measure of required effort to implementing tasks. The main idea is you provide an estimate for the number of ''unobstructed development days or hours'' needed for completing a task. While this is also very easy and intuitive to use, it can be implemented with almost the same benefits as estimating with story points can. This is because the metrics can often be used interchangeably:		'''With Ideal Days''' you apply an absolute measure of required effort to implementing tasks. The main idea is you provide an estimate for the number of ''unobstructed development days or hours'' needed for completing a task. While this is also very easy and intuitive to use, it can be implemented with almost the same benefits as estimating with story points can. This is because the metrics can often be used interchangeably:

	''"Imagine a team estimating using Ideal Days having a backlog of tasks requiring 0.5 day, 1 day, 2 days etc. Now, convert each of these estimations into Story Points using a 1:1 scale: 0.5 Ideal Days = 0.5 Story Points, 1 Ideal Day = 1 Story Point and so on... Although it doesn't necessarily fit with the Fibonacci sequence (as proposed in the example guideline above) the team will still be able to commit a certain number of point to each sprint, measure velocity, get an idea of current overhead, break down large tasks into smaller etc. just like when using the Story Point estimation tool.~~"''~~		''"Imagine a team estimating using Ideal Days having a backlog of tasks requiring 0.5 day, 1 day, 2 days etc. Now, convert each of these estimations into Story Points using a 1:1 scale: 0.5 Ideal Days = 0.5 Story Points, 1 Ideal Day = 1 Story Point and so on..."''

			Although it doesn't necessarily fit with the Fibonacci sequence (as proposed in the example guideline above) the team will still be able to commit a certain number of point to each sprint, measure velocity, get an idea of current overhead, break down large tasks into smaller etc. just like when using the Story Point estimation tool.
	A story thought to last one Ideal Day typically takes a lot longer to implement than one work day. This is because the tool doesn't take into consideration interruptions such as meetings or unexpected problems such as computer-failure i.a.		A story thought to last one Ideal Day typically takes a lot longer to implement than one work day. This is because the tool doesn't take into consideration interruptions such as meetings or unexpected problems such as computer-failure i.a.
	The team should take special care when estimating Ideal Days, unlike Story Points, that takes input from the whole team, Ideal Days may vary greatly between developers; a task that would take one developer half a day might take another 2 days to implement. People not only have different schedules that might affect the number of Ideal Days, but also has different skill levels to take into consideration.		The team should take special care when estimating Ideal Days, unlike Story Points, that takes input from the whole team, Ideal Days may vary greatly between developers; a task that would take one developer half a day might take another 2 days to implement. People not only have different schedules that might affect the number of Ideal Days, but also has different skill levels to take into consideration.

S113735: /* Alternatives */

2015-09-27T21:36:24Z

Alternatives

← Older revision		Revision as of 21:36, 27 September 2015
Line 81:		Line 81:

	= Alternatives =		= Alternatives =
	There are a number of ways to estimating and measuring size of software projects alternative to using Story Points. Among these alternative ways are measuring ''Lines of Code'' (LOC), ''Thousand Lines of Code'' (KLOC) or ''Ideal Days''.<ref> Georgsson, Anna (2011) [http://www.diva-portal.org/smash/get/diva2:400313/FULLTEXT01.pdf ''A Case Study at Swedbank IT''], p. 15, Master Thesis, Umeå University </ref> Another obvious alternative is simply to estimate using ''Hours''.		There are a number of ways to estimating and measuring the size of software projects alternative to using Story Points. Among these alternative ways are measuring ''Lines of Code'' (LOC), ''Thousand Lines of Code'' (KLOC) or ''Ideal Days''.<ref> Georgsson, Anna (2011) [http://www.diva-portal.org/smash/get/diva2:400313/FULLTEXT01.pdf ''A Case Study at Swedbank IT''], p. 15, Master Thesis, Umeå University </ref> Another obvious alternative is to simply estimate using ''Hours''.

	== Lines of Code ==		== Lines of Code ==
	'''Using LOC or KLOC''' simply estimates the size of the project in regards to the lines that needs to be coded. These methods don't take into account the complexity of the tasks, but have shown to be decent indications of required effort.<ref> [https://en.wikipedia.org/wiki/Source_lines_of_code ''Source Lines of Code''], Wikipedia </ref> While these two tools are fairly easy to use, the number of Lines Coded has almost no correlation with program functionality or quality~~, which~~ often ~~results~~ in the tools being seen as a less desirable practice.		'''Using LOC or KLOC''' simply estimates the size of the project in regards to the lines that needs to be coded. These methods don't take into account the complexity of the tasks, but have shown to be decent indications of required effort.<ref> [https://en.wikipedia.org/wiki/Source_lines_of_code ''Source Lines of Code''], Wikipedia </ref> While these two tools are fairly easy to use, the number of Lines Coded has almost no correlation with program functionality or quality. This often result in the tools being seen as a less desirable practice.
	LOC is an intuitive tool that is easy to use and most can relate to. However, unlike Story Points, only developers take part in estimating LOC. While this reduces overhead considerably, ~~at the same time~~ it provides some inherent project uncertainty.		LOC is an intuitive tool that is easy to use and most can relate to. However, unlike Story Points, only developers take part in estimating LOC. While this reduces overhead considerably, it also provides some inherent project uncertainty.

	== Ideal Days ==		== Ideal Days ==
	'''With Ideal Days''' you apply an absolute measure of required effort to implementing tasks. The main idea is you provide an estimate for the number of ''unobstructed development days or hours'' needed for completing a task. While this is also very easy and intuitive to use, it can be implemented with almost the same benefits as estimating with story points can. This is because the metrics can often be used interchangeably:		'''With Ideal Days''' you apply an absolute measure of required effort to implementing tasks. The main idea is you provide an estimate for the number of ''unobstructed development days or hours'' needed for completing a task. While this is also very easy and intuitive to use, it can be implemented with almost the same benefits as estimating with story points can. This is because the metrics can often be used interchangeably:
	''Imagine a team estimating using Ideal Days having a backlog of tasks requiring 0.5 day, 1 day, 2 days etc. Now, convert each of these estimations into Story Points using a 1:1 scale: 0.5 Ideal Days = 0.5 Story Points, 1 Ideal Day = 1 Story Point and so on... Although it doesn't necessarily fit with the Fibonacci sequence the team will still be able to commit a certain number of point to each sprint, measure velocity, get an idea of current overhead, break down large tasks into smaller etc. just like when using the Story Point estimation tool.
	A story thought to ~~take an~~ Ideal Day typically takes a lot longer to implement than one work day. This is because the tool doesn't take into consideration interruptions such as meetings or unexpected problems such as computer-failure i.a.		''"Imagine a team estimating using Ideal Days having a backlog of tasks requiring 0.5 day, 1 day, 2 days etc. Now, convert each of these estimations into Story Points using a 1:1 scale: 0.5 Ideal Days = 0.5 Story Points, 1 Ideal Day = 1 Story Point and so on... Although it doesn't necessarily fit with the Fibonacci sequence (as proposed in the example guideline above) the team will still be able to commit a certain number of point to each sprint, measure velocity, get an idea of current overhead, break down large tasks into smaller etc. just like when using the Story Point estimation tool."''
			A story thought to last one Ideal Day typically takes a lot longer to implement than one work day. This is because the tool doesn't take into consideration interruptions such as meetings or unexpected problems such as computer-failure i.a.
	The team should take special care when estimating Ideal Days, unlike Story Points, that takes input from the whole team, Ideal Days may vary greatly between developers; a task that would take one developer half a day might take another 2 days to implement. People not only have different schedules that might affect the number of Ideal Days, but also has different skill levels to take into consideration.		The team should take special care when estimating Ideal Days, unlike Story Points, that takes input from the whole team, Ideal Days may vary greatly between developers; a task that would take one developer half a day might take another 2 days to implement. People not only have different schedules that might affect the number of Ideal Days, but also has different skill levels to take into consideration.