Internal: Estimating Projects - Revision history

John.meegan at 04:04, 9 March 2016

2016-03-09T04:04:26Z

←Older revision		Revision as of 04:04, 9 March 2016
Line 20:		Line 20:
	* '''Documentation''' -- For Context Summary Help.		* '''Documentation''' -- For Context Summary Help.
	* '''Validation''' -- "release testing" at the end		* '''Validation''' -- "release testing" at the end
	* '''Maintenance''' -- Estimates need to take into account time to fix bugs that come back from testing and reviewing, not just time on the original issues~~. This is post-project work~~.
			Estimates need to take into account time to fix bugs that come back from testing and reviewing, not just time on the original issues.

John.meegan at 00:25, 9 March 2016

2016-03-09T00:25:06Z

←Older revision		Revision as of 00:25, 9 March 2016
Line 20:		Line 20:
	* '''Documentation''' -- For Context Summary Help.		* '''Documentation''' -- For Context Summary Help.
	* '''Validation''' -- "release testing" at the end		* '''Validation''' -- "release testing" at the end
			* '''Maintenance''' -- Estimates need to take into account time to fix bugs that come back from testing and reviewing, not just time on the original issues. This is post-project work.


	~~Estimates need to take into account time to fix bugs that come back from testing and reviewing, not just time on the original issues. This is post-project work.~~

John.meegan at 00:13, 9 March 2016

2016-03-09T00:13:42Z

←Older revision		Revision as of 00:13, 9 March 2016
Line 17:		Line 17:
	* '''Writing requirements documents''' -- if not already done		* '''Writing requirements documents''' -- if not already done
	* '''Coding'''		* '''Coding'''
	* '''Testing & Rework''' -- there’s no general rule for this. Sometimes changes take ages but are easy to test, sometimes they are small changes but take ages to test. One line of core code is very different to 100 lines of UI code.		* '''Testing & Rework''' -- there’s no general rule for this. Sometimes changes take ages but are easy to test, sometimes they are small changes but take ages to test. One line of core code is very different to 100 lines of UI code.
	* '''Documentation''' -- For Context Summary Help.		* '''Documentation''' -- For Context Summary Help.
	* '''Validation''' -- "release testing" at the end		* '''Validation''' -- "release testing" at the end

			Estimates need to take into account time to fix bugs that come back from testing and reviewing, not just time on the original issues. This is post-project work.

John.meegan at 05:01, 8 March 2016

2016-03-08T05:01:10Z

←Older revision		Revision as of 05:01, 8 March 2016
Line 18:		Line 18:
	* '''Coding'''		* '''Coding'''
	* '''Testing & Rework''' -- there’s no general rule for this. Sometimes changes take ages but are easy to test, sometimes they are small changes but take ages to test. One line of core code is very different to 100 lines of UI code.		* '''Testing & Rework''' -- there’s no general rule for this. Sometimes changes take ages but are easy to test, sometimes they are small changes but take ages to test. One line of core code is very different to 100 lines of UI code.
			* '''Documentation''' -- For Context Summary Help.
	* '''Validation''' -- "release testing" at the end		* '''Validation''' -- "release testing" at the end

John.meegan at 05:01, 1 March 2016

2016-03-01T05:01:41Z

←Older revision		Revision as of 05:01, 1 March 2016
Line 15:		Line 15:

	Include estimates for:		Include estimates for:
	* '''Writing requirements documents''' - if not already done		* '''Writing requirements documents''' -- if not already done
	* '''Coding'''		* '''Coding'''
	* '''Testing & Rework''' -- there’s no general rule for this. Sometimes changes take ages but are easy to test, sometimes they are small changes but take ages to test. One line of core code is very different to 100 lines of UI code.		* '''Testing & Rework''' -- there’s no general rule for this. Sometimes changes take ages but are easy to test, sometimes they are small changes but take ages to test. One line of core code is very different to 100 lines of UI code.

John.meegan at 04:23, 1 March 2016

2016-03-01T04:23:19Z

←Older revision		Revision as of 04:23, 1 March 2016
Line 18:		Line 18:
	* '''Coding'''		* '''Coding'''
	* '''Testing & Rework''' -- there’s no general rule for this. Sometimes changes take ages but are easy to test, sometimes they are small changes but take ages to test. One line of core code is very different to 100 lines of UI code.		* '''Testing & Rework''' -- there’s no general rule for this. Sometimes changes take ages but are easy to test, sometimes they are small changes but take ages to test. One line of core code is very different to 100 lines of UI code.
	* '''Validation'''		* '''Validation''' -- "release testing" at the end

John.meegan at 04:18, 1 March 2016

2016-03-01T04:18:03Z

←Older revision		Revision as of 04:18, 1 March 2016
Line 6:		Line 6:

	= Estimating Projects =		= Estimating Projects =

			For one issue you’re almost never going to get it right, but for groups of work our estimates get better because if say 90% are done earlier than estimated, and 10% blow out, the overall amount is about right. So if you provide a “bit” of slack for each issue then you should be safe.

	It is useful to group issues into 3 pools, then estimate issues individually based on these:		It is useful to group issues into 3 pools, then estimate issues individually based on these:
Line 17:		Line 19:
	* '''Testing & Rework''' -- there’s no general rule for this. Sometimes changes take ages but are easy to test, sometimes they are small changes but take ages to test. One line of core code is very different to 100 lines of UI code.		* '''Testing & Rework''' -- there’s no general rule for this. Sometimes changes take ages but are easy to test, sometimes they are small changes but take ages to test. One line of core code is very different to 100 lines of UI code.
	* '''Validation'''		* '''Validation'''

John.meegan at 04:16, 1 March 2016

2016-03-01T04:16:27Z

←Older revision		Revision as of 04:16, 1 March 2016
Line 13:		Line 13:

	Include estimates for:		Include estimates for:
	* Writing requirements documents (if not already done)		* '''Writing requirements documents''' - if not already done
	* Coding		* '''Coding'''
	* Testing & Rework		* '''Testing & Rework''' -- there’s no general rule for this. Sometimes changes take ages but are easy to test, sometimes they are small changes but take ages to test. One line of core code is very different to 100 lines of UI code.
	* Validation		* '''Validation'''

John.meegan at 04:13, 1 March 2016

2016-03-01T04:13:36Z

←Older revision	Revision as of 04:13, 1 March 2016
Line 5:	Line 5:


		= Estimating Projects =

		It is useful to group issues into 3 pools, then estimate issues individually based on these:
		* Hard
		* Medium
		* Easy

		Include estimates for:
		* Writing requirements documents (if not already done)
		* Coding
		* Testing & Rework
		* Validation

John.meegan at 04:10, 1 March 2016

2016-03-01T04:10:27Z

New page

<noinclude>
[[QESTLab_Internal:Developer_Home|Developer Home]]
----
</noinclude>

<noinclude>
----
[[QESTLab_Internal:Developer_Home|Developer Home]]
</noinclude>