Changes for page Agile and Data

Last modified by chrisby on 2024/01/13 17:13

From version 11.9
edited by chrisby
on 2023/12/19 15:23
Change comment: There is no comment for this version
To version 11.5
edited by chrisby
on 2023/12/16 14:53
Change comment: There is no comment for this version

Summary

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  
... ... @@ -37,11 +37,11 @@
37 37  
38 38  ### How to Handle Delays?
39 39  
40 -**Scope vs Schedule**: In many classic projects, the scope and the schedule are fixed. However, since the effort and requirements of software projects are almost impossible to accurately determine, it is unreasonable for management to demand the same fixation of scope and schedule. Therefore, either the scope must be flexible and the schedule fixed, or vice versa. This relationship explains the strategies for dealing with the problem when the generated agile data indicates that there will be a delay:
40 +**Scope vs Schedule**: In many classic projects, the scope and the schedule are fixed. However, since the effort and requirements of software projects are almost impossible to accurately determine, it is unreasonable to demand the same fixation of scope and schedule. Therefore, either the scope must be flexible and the schedule fixed, or vice versa. This relationship explains the strategies for dealing with the problem when the generated agile data indicates that there will be a delay:
41 41  
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 -* **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.
42 +* **Schedule Adaption**: It's sometimes possible to postpone the deadline, although this is often not an acceptable option for management.
43 +* **Scope Adaption**: Stakeholders prioritize features with the highest return of investment (RoI) and remove features with lower RoI from the project scope.
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. **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.
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.
46 46  
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.
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.