Changes for page Agile and Data

Summary

• Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

...	...	@@ -7,7 +7,7 @@
7	7	![[velocity-time-chart_white.svg|velocity-time-chart_white.svg]]
8	8
9	9	* x-axis: Time in iterations or dates (the last day of each iteration)
10		-* y-axis: Velocity = points of completed stories within one iteration
	10	+* y-axis: **Velocity** = points of completed stories within one iteration
11	11	* The first data point is generated after the first story implementation iteration.
12	12	* After a few iterations, the average velocity should be roughly constant for the rest of the project.
13	13
...	...	@@ -16,7 +16,7 @@
16	16	**![[burndown-chart_white_v2.svg|burndown-chart_white_v2.svg]]**
17	17
18	18	* x-axis: same as in velocity-time chart
19		-* y-axis: Points remaining = sum of points from unfinished stories
	19	+* y-axis: Points Remaining = sum of points from unfinished stories
20	20	* The first point starts at the very beginning of the project and is therefore at x = 0, just above the y-axis. It is the sum of the effort estimates of all stories. The second data point is generated after the first story implementation iteration.
21	21	* The linear approximation function of the data points has a negative slope. The deck of stories is completed over time, so the graph "burns down" over time, hence the name.
22	22
...	...	@@ -33,7 +33,7 @@
33	33
34	34	### Declining Velocity
35	35
36		-The most likely reason for declining velocity is poor code quality due to lack of refactoring and testing. Don't hide it, don't artificially inflate the velocity (see "[[Golden Story|doc:Software Engineering.Agile.Extreme Programming.Planning Game.Effort Estimation.WebHome]]"), just invest more time in refactoring and testing to improve code quality.
	36	+Ideally, velocity remains constant and the team makes steady progress. But if it drops, the most likely reason is poor code quality due to lack of refactoring and testing. Don't hide it, don't artificially inflate the velocity (see "[[Golden Story|doc:Software Engineering.Agile.Extreme Programming.Planning Game.Effort Estimation.WebHome]]"), just invest more time in refactoring and testing to improve code quality.
37	37
38	38	### How to Handle Delays?
39	39
...	...	@@ -42,6 +42,6 @@
42	42	* **Schedule Adaption**: It's sometimes possible to push back the deadline to give developers more time to implement all the stories, although this is often not an acceptable option for management.
43	43	* **Scope Adaption**: Stakeholders prioritize features with the highest return on investment (ROI) and remove features with lower ROI from the project scope to meet the original deadline.
44	44
45		-**Personnel Increase**: An alternative to the above strategies may be to invest more human resources in the project. Ideally, neither scope nor schedule need be adjusted. Note that this will result in a short-term drop in productivity, as the new team members require the attention of the original team members (explanations, answering questions, joint familiarization with the project, etc.), which distracts them from their actual work. After this period, productivity will rise above the original productivity as desired.
	45	+**Personnel Increase**: An alternative to the above strategies may be to invest more human resources in the project. Ideally, neither scope nor schedule need be adjusted. Note that this will result in a short-term drop in productivity, as the new team members require the attention of the original team members (explanations, answering questions, joint familiarization with the project, etc.), which distracts them from their actual work. After this period, productivity will rise above the original productivity as desired. **Brook's Law** is an inference from this fact, which states that adding personnel to a late project will delay it even further due to the initial drop in productivity.
46	46
47	47	**Never Sacrifice Quality**: Decreasing code quality by omitting testing or refactoring, with the intention of saving time, actually slows development and adds to technical debt. This is not an option at all.