Agile Estimation - Revision history

Mmusij: /* Story Points */

2021-06-17T03:54:24Z

Story Points

← Older revision		Revision as of 03:54, 17 June 2021
Line 32:		Line 32:

	==Story Points==		==Story Points==
	Story Points are a measure of complexity or effort needed to complete a [[User ~~Story~~]] to a ''potentially shippable'', or ''done, done, done'' state. They are ''abstract'', in that, they do not relate to time but instead are a magnitude of effort needed to complete a work item in very much the same way as we considered rocks in the example above.		Story Points are a measure of complexity or effort needed to complete [[User Stories]] to a ''potentially shippable'', or ''done, done, done'' state. They are ''abstract'', in that, they do not relate to time but instead are a magnitude of effort needed to complete a work item in very much the same way as we considered rocks in the example above.

	===Story Points as a Unit of Measure===		===Story Points as a Unit of Measure===

Mmusij: /* See Also */

2021-06-16T01:14:03Z

Mmusij: /* Estimation Techniques */

2021-06-16T01:12:18Z

Estimation Techniques

← Older revision		Revision as of 01:12, 16 June 2021
Line 50:		Line 50:
	==Estimation Techniques==		==Estimation Techniques==
	* [[Planning Poker]] is a basic technique that allows a team to provide a detailed estimate based upon a holistic approach to complete a work item. This technique can be a little slow when compared to others.		* [[Planning Poker]] is a basic technique that allows a team to provide a detailed estimate based upon a holistic approach to complete a work item. This technique can be a little slow when compared to others.
	* [[Affinity ~~Sizing~~]] is a simple technique that allows a quick rough estimate to be provided, and is useful is a large number of items are needed to be estimated quickly such as when initially creating a [[Scrum Artefacts#Product Backlog\|Product Backlog]] for example.		* [[Affinity Estimation]] is a simple technique that allows a quick rough estimate to be provided, and is useful is a large number of items are needed to be estimated quickly such as when initially creating a [[Scrum Artefacts#Product Backlog\|Product Backlog]] for example.

	==See Also==		==See Also==

Mmusij: /* Techniques */

2019-03-14T01:32:27Z

Techniques

← Older revision		Revision as of 01:32, 14 March 2019
Line 48:		Line 48:
	* 2 Power Series - 0, 1, 2, 4, 8, 16, 32, 64, 128, 256, ...		* 2 Power Series - 0, 1, 2, 4, 8, 16, 32, 64, 128, 256, ...

	==Techniques==		==Estimation Techniques==
	* [[Planning Poker]] is a basic technique that allows a team to provide a detailed estimate based upon a holistic approach to complete a work item. This technique can be a little slow when compared to others.		* [[Planning Poker]] is a basic technique that allows a team to provide a detailed estimate based upon a holistic approach to complete a work item. This technique can be a little slow when compared to others.
	* [[Affinity Sizing]] is a simple technique that allows a quick rough estimate to be provided, and is useful is a large number of items are needed to be estimated quickly such as when initially creating a [[Scrum Artefacts#Product Backlog\|Product Backlog]] for example.		* [[Affinity Sizing]] is a simple technique that allows a quick rough estimate to be provided, and is useful is a large number of items are needed to be estimated quickly such as when initially creating a [[Scrum Artefacts#Product Backlog\|Product Backlog]] for example.

Mmusij: /* Exponential Scales */

2019-03-14T01:32:04Z

Exponential Scales

← Older revision		Revision as of 01:32, 14 March 2019
Line 44:		Line 44:
	There are several popular exponential scales and include:		There are several popular exponential scales and include:

	* Planning Poker ~~Series(R)~~ - 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100, ∞		* Planning Poker Series® - 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100, ∞
	* Fibonacci Series - 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89...		* Fibonacci Series - 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89...
	* 2 Power Series - 0, 1, 2, 4, 8, 16, 32, 64, 128, 256, ...		* 2 Power Series - 0, 1, 2, 4, 8, 16, 32, 64, 128, 256, ...

Mmusij at 01:31, 14 March 2019

2019-03-14T01:31:17Z

← Older revision		Revision as of 01:31, 14 March 2019
Line 7:		Line 7:
	This article addresses the former situation when a forward predictive estimate is needed.		This article addresses the former situation when a forward predictive estimate is needed.

	==~~Story Points~~==		==Velocity==
	This approach of using abstract units of measure for estimates often causes quite a bit of confusion especially if teams are conditioned to use time based estimates.		This approach of using abstract units of measure for estimates often causes quite a bit of confusion especially if teams are conditioned to use time based estimates, and so here is a simple example of how to use abstract measures with time-boxes:

	~~Story Points are used to indicate the size of effort or complexity associated with~~ a ~~[[User Stories\|User Story]] or work item in terms~~ of ~~the amount of effort~~ to ~~complete it to a ''potentially shippable'', or ''done, done, done'' state. They are ''~~abstract~~'', in that, they do not relate to~~ time ~~but instead are a magnitude of effort needed to complete a work item.~~

	~~==Velocity==~~
	Consider a situation where we have a number of equal sized rocks and need to transport them from station A to station B. A traditional estimation approach would involve guessing how long it would take to move all of the rocks to station B. An agile approach by comparison will involve obtaining a few samples first and then obtaining an average velocity.		Consider a situation where we have a number of equal sized rocks and need to transport them from station A to station B. A traditional estimation approach would involve guessing how long it would take to move all of the rocks to station B. An agile approach by comparison will involve obtaining a few samples first and then obtaining an average velocity.

Line 26:		Line 23:
	#* In our example 15 rocks / 1.5 velocity = 10 time-boxes or sprints that are 30 seconds long = 300 seconds = 5 minutes		#* In our example 15 rocks / 1.5 velocity = 10 time-boxes or sprints that are 30 seconds long = 300 seconds = 5 minutes
	# As we do more sprints or iterations the accuracy of our average velocity improves helping us to understand how long it will take to move all of the rocks		# As we do more sprints or iterations the accuracy of our average velocity improves helping us to understand how long it will take to move all of the rocks

			===Relative Sizing===
			In the example we considered all rocks to be of an equal size, but we can also use different sized rocks relative to each other. That is, when looking at the rocks we may see that one rock is twice as large as another rock, which also implies that there is twice as much effort to move it from station A to station B.

			If we repeat the process and look at another rock we might see that it is twice as large as the first rock and so four times bigger than the smallest rock, implying four times the effort needed.

			This is relative sizing and is done by comparing items of work with each other and making judgements based upon how much effort is involved relative to each other.

			==Story Points==
			Story Points are a measure of complexity or effort needed to complete a [[User Story]] to a ''potentially shippable'', or ''done, done, done'' state. They are ''abstract'', in that, they do not relate to time but instead are a magnitude of effort needed to complete a work item in very much the same way as we considered rocks in the example above.

	===Story Points as a Unit of Measure===		===Story Points as a Unit of Measure===
Line 32:		Line 39:
	Story Points then become an indication of how much work is attributed to a work item, or User Story.		Story Points then become an indication of how much work is attributed to a work item, or User Story.

	===~~Relative Sizing~~===		===Exponential Scales===
	~~Using~~ an ~~abstract measure such as Story Points~~ to ~~provide~~ an ~~indicator of effort tends to work best when work items~~ or ~~User Stories are compared and can be sized relative to each other. For example, a work item or User~~ Story ~~can be sized relative to another by asking simple questions such as ''"is this more or less effort than the other item?"'' and ''"is this item twice or 3 times more effort than another item?"''~~.		The general premise is that the larger something is, the more unknowns are attributable to it and so an exponential scale is used to reflect the number of unknowns associated with an estimate or Story Point number.

	With relative sizing, the first item to be sized is the hardest as it then sets the benchmark for others relative to it. Hence, it is recommended to initially find a work item that is a small size that can then be sized and ~~other items sized relative to it.~~		There are several popular exponential scales and include:

	~~As more items are sized then the Story Point sizes begin to normalise and it gets easier to size additional items as there are more to compare them to~~.		* Planning Poker Series(R) - 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100, ∞
			* Fibonacci Series - 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89...
			* 2 Power Series - 0, 1, 2, 4, 8, 16, 32, 64, 128, 256, ...

	==Techniques==		==Techniques==

Mmusij: /* Velocity */

2019-03-14T01:13:06Z

Velocity

← Older revision		Revision as of 01:13, 14 March 2019
Line 16:		Line 16:

	# Set the timer for 30s and see how many rocks we can move in that time from station A to station B		# Set the timer for 30s and see how many rocks we can move in that time from station A to station B
	** In our example we manage to move 1 rock in 30 seconds		#* In our example we manage to move 1 rock in 30 seconds
	# Repeat the same step again, setting the timer to 30s and see how many rocks we can move in the time-box		# Repeat the same step again, setting the timer to 30s and see how many rocks we can move in the time-box
	** In our example we manage to move 2 rocks this time in 30 seconds		#* In our example we manage to move 2 rocks this time in 30 seconds
	# Now we can take an average of the two time-boxes		# Now we can take an average of the two time-boxes
	** In our example this is 3 rocks / 2 time-boxes = 1.5 rocks per time-box (or a velocity of 1.5)		#* In our example this is 3 rocks / 2 time-boxes = 1.5 rocks per time-box (or a velocity of 1.5)
	# All we have to do now is total up the number of rocks to be moved		# All we have to do now is total up the number of rocks to be moved
	** In our example there are 15 rocks to be moved		#* In our example there are 15 rocks to be moved
	# Divide the total number of rocks by the velocity now gives us the number of time-boxes, [[Sprints]] or iterations it will take to move all of the rocks		# Divide the total number of rocks by the velocity now gives us the number of time-boxes, [[Sprints]] or iterations it will take to move all of the rocks
	** In our example 15 rocks / 1.5 velocity = 10 time-boxes or sprints that are 30 seconds long = 300 seconds = 5 minutes		#* In our example 15 rocks / 1.5 velocity = 10 time-boxes or sprints that are 30 seconds long = 300 seconds = 5 minutes
	# As we do more sprints or iterations the accuracy of our average velocity improves helping us to understand how long it will take to move all of the rocks		# As we do more sprints or iterations the accuracy of our average velocity improves helping us to understand how long it will take to move all of the rocks

Mmusij: /* Velocity */

2019-03-14T01:12:38Z

Velocity

← Older revision		Revision as of 01:12, 14 March 2019
Line 16:		Line 16:

	# Set the timer for 30s and see how many rocks we can move in that time from station A to station B		# Set the timer for 30s and see how many rocks we can move in that time from station A to station B
	## In our example we manage to move 1 rock in 30 seconds		** In our example we manage to move 1 rock in 30 seconds
	# Repeat the same step again, setting the timer to 30s and see how many rocks we can move in the time-box		# Repeat the same step again, setting the timer to 30s and see how many rocks we can move in the time-box
	## In our example we manage to move 2 rocks this time in 30 seconds		** In our example we manage to move 2 rocks this time in 30 seconds
	# Now we can take an average of the two time-boxes		# Now we can take an average of the two time-boxes
	## In our example this is 3 rocks / 2 time-boxes = 1.5 rocks per time-box (or a velocity of 1.5)		** In our example this is 3 rocks / 2 time-boxes = 1.5 rocks per time-box (or a velocity of 1.5)
	# All we have to do now is total up the number of rocks to be moved		# All we have to do now is total up the number of rocks to be moved
	## In our example there are 15 rocks to be moved		** In our example there are 15 rocks to be moved
	# Divide the total number of rocks by the velocity now gives us the number of time-boxes, [[Sprints]] or ~~[[Iterations]]~~ it will take to move all of the rocks		# Divide the total number of rocks by the velocity now gives us the number of time-boxes, [[Sprints]] or iterations it will take to move all of the rocks
	## In our example 15 rocks / 1.5 velocity = 10 time-boxes or sprints that are 30 seconds long = 300 seconds = 5 minutes		** In our example 15 rocks / 1.5 velocity = 10 time-boxes or sprints that are 30 seconds long = 300 seconds = 5 minutes
	# As we do more sprints or iterations the accuracy of our average velocity improves helping us to understand how long it will take to move all of the rocks		# As we do more sprints or iterations the accuracy of our average velocity improves helping us to understand how long it will take to move all of the rocks

Mmusij at 01:11, 14 March 2019

2019-03-14T01:11:57Z

← Older revision		Revision as of 01:11, 14 March 2019
Line 11:		Line 11:

	Story Points are used to indicate the size of effort or complexity associated with a [[User Stories\|User Story]] or work item in terms of the amount of effort to complete it to a ''potentially shippable'', or ''done, done, done'' state. They are ''abstract'', in that, they do not relate to time but instead are a magnitude of effort needed to complete a work item.		Story Points are used to indicate the size of effort or complexity associated with a [[User Stories\|User Story]] or work item in terms of the amount of effort to complete it to a ''potentially shippable'', or ''done, done, done'' state. They are ''abstract'', in that, they do not relate to time but instead are a magnitude of effort needed to complete a work item.

			==Velocity==
			Consider a situation where we have a number of equal sized rocks and need to transport them from station A to station B. A traditional estimation approach would involve guessing how long it would take to move all of the rocks to station B. An agile approach by comparison will involve obtaining a few samples first and then obtaining an average velocity.

			# Set the timer for 30s and see how many rocks we can move in that time from station A to station B
			## In our example we manage to move 1 rock in 30 seconds
			# Repeat the same step again, setting the timer to 30s and see how many rocks we can move in the time-box
			## In our example we manage to move 2 rocks this time in 30 seconds
			# Now we can take an average of the two time-boxes
			## In our example this is 3 rocks / 2 time-boxes = 1.5 rocks per time-box (or a velocity of 1.5)
			# All we have to do now is total up the number of rocks to be moved
			## In our example there are 15 rocks to be moved
			# Divide the total number of rocks by the velocity now gives us the number of time-boxes, [[Sprints]] or [[Iterations]] it will take to move all of the rocks
			## In our example 15 rocks / 1.5 velocity = 10 time-boxes or sprints that are 30 seconds long = 300 seconds = 5 minutes
			# As we do more sprints or iterations the accuracy of our average velocity improves helping us to understand how long it will take to move all of the rocks

	===Story Points as a Unit of Measure===		===Story Points as a Unit of Measure===

Mmusij: /* Techniques */

2019-01-25T00:07:26Z

Techniques

← Older revision		Revision as of 00:07, 25 January 2019
Line 26:		Line 26:
	==Techniques==		==Techniques==
	* [[Planning Poker]] is a basic technique that allows a team to provide a detailed estimate based upon a holistic approach to complete a work item. This technique can be a little slow when compared to others.		* [[Planning Poker]] is a basic technique that allows a team to provide a detailed estimate based upon a holistic approach to complete a work item. This technique can be a little slow when compared to others.
	* [[Affinity Sizing]] is a simple technique that allows a quick rough estimate to be provided, and is useful is a large number of items are needed to be estimated quickly such as when initially creating a [[Product Backlog]] for example.		* [[Affinity Sizing]] is a simple technique that allows a quick rough estimate to be provided, and is useful is a large number of items are needed to be estimated quickly such as when initially creating a [[Scrum Artefacts#Product Backlog\|Product Backlog]] for example.

	==See Also==		==See Also==

← Older revision		Revision as of 01:14, 16 June 2021
Line 53:		Line 53:

	==See Also==		==See Also==
			* [[T-Shirt Sizing]]
	* [[Agile Metrics]]		* [[Agile Metrics]]
	* [[User Stories]]		* [[User Stories]]