Content
View differences
Updated by Parimal Satyal over 2 years ago
**As a** project manager,
**I want to** manually set the % complete status of a work packge
**so that** I have more influence in what I communicate to my stakeholder
**As a** project member (eg. a developer),
**I want to** be able to quickly update how much progress I think I've made on a Feature or a User story
**So that** my team (including my manager) has a overall perspective on progress on an Epic or a Project in general
### **Context**
This complements (or completes) another feature:
###40749
With that, the _**% complete**_ field will require and be a function of the value of _Work_ (and consequently, _Remaining work_). This change makes makes progress reporting more grounded in reality but also introduces complexity:
* Progress cannot be manually input (like it is possible today) without also inputing a value for work.
* Progress then logically also becomes tied to the notion of _work done_ (or _earned value_), or, alternatively, to _time spent_. In either case, it's more information is needed to be able to calculate progress.
This means that the field represents a form of **calculated progress** expressed as a percentage a total (% complete) relative to (estimated) work and remaining work
For certain users, organisations and projects, however, there might be value in reporting progress manually, unconnected to other fields. This feature introduces the notion of **Reported progress** to afford just that possibility.
### **Acceptance criteria**
* There is a new field called **Reported progress**
* Migration: Existing _% complete_ values will be migrated to this field
* Or rather, logically, the current "% complete" will be renamed "Reported progress" and a new attribute called "Calculated progress" will be introduced for <mention class="mention" data-id="40749" data-type="work_package" data-text="#40749">#40749</mention>
* The value is self-reported and manually entered and unaffected by other values (like _Work_, _Remaining work_ or _Time spent_)
* OpenProject can be configured to automatically set fixed reported progress values based on status.
* Example: in our own case here at OpenProject, these could be:
* New = 0%
* In specification = 20%
* Specified = 40%
* In development = 50%
* Needs review = 80%
* In testing = 90%
* Tested = 99%
* Closed = 100%
* Rejected = current value conserved but ignored in sums
* Status changes can update Reported progress but it's not a direct connection; the value remains manually editable.
* Setting a feature to "In development" will set it at 50% automatically, but a user can go ahead and change it to 60% or even 100% if she wants, without affecting status
* _... (specification in progress)_
### **User Feedback**
**Task:** Contact around five different OpenProject users of different sizes and ask them:
* How they currently use the progress field (or how they report progress)
* What works for them and what doesn't
* To share screenshots of views they currently use (if possible).
We should a variety of different _types_ of usages in the same: for example, a large public organisations, a small NGO, a mid-sized company, perhaps a scientific team...
### **Open questions**
* **Sum:** Should it be possible to sum Reported progress?
* \[PS: Yes. Why not?\]
* **Reported and/or Calculated:** Should it be possible to use both Reported progress and Calculated progress (% progress) at the same time? Or should use users have to pick one or the other?
### Figma
https://www.figma.com/file/znrocQvFNLb5jXRXNo7oeD/Progress-estimation?type=design&node-id=1010-7036&mode=design
**I want to** manually set the % complete status of a work packge
**so that** I have more influence in what I communicate to my stakeholder
**As a** project member (eg. a developer),
**I want to** be able to quickly update how much progress I think I've made on a Feature or a User story
**So that** my team (including my manager) has a overall perspective on progress on an Epic or a Project in general
### **Context**
This complements (or completes) another feature:
###40749
With that, the _**% complete**_ field will require and be a function of the value of _Work_ (and consequently, _Remaining work_). This change makes makes progress reporting more grounded in reality but also introduces complexity:
* Progress cannot be manually input (like it is possible today) without also inputing a value for work.
* Progress then logically also becomes tied to the notion of _work done_ (or _earned value_), or, alternatively, to _time spent_. In either case, it's more information is needed to be able to calculate progress.
This means that the field represents a form of **calculated progress** expressed as a percentage a total (% complete) relative to (estimated) work and remaining work
For certain users, organisations and projects, however, there might be value in reporting progress manually, unconnected to other fields. This feature introduces the notion of **Reported progress** to afford just that possibility.
### **Acceptance criteria**
* There is a new field called **Reported progress**
* Migration: Existing _% complete_ values will be migrated to this field
* Or rather, logically, the current "% complete" will be renamed "Reported progress" and a new attribute called "Calculated progress" will be introduced for <mention class="mention" data-id="40749" data-type="work_package" data-text="#40749">#40749</mention>
* The value is self-reported and manually entered and unaffected by other values (like _Work_, _Remaining work_ or _Time spent_)
* OpenProject can be configured to automatically set fixed reported progress values based on status.
* Example: in our own case here at OpenProject, these could be:
* New = 0%
* In specification = 20%
* Specified = 40%
* In development = 50%
* Needs review = 80%
* In testing = 90%
* Tested = 99%
* Closed = 100%
* Rejected = current value conserved but ignored in sums
* Status changes can update Reported progress but it's not a direct connection; the value remains manually editable.
* Setting a feature to "In development" will set it at 50% automatically, but a user can go ahead and change it to 60% or even 100% if she wants, without affecting status
* _... (specification in progress)_
### **User Feedback**
**Task:** Contact around five different OpenProject users of different sizes and ask them:
* How they currently use the progress field (or how they report progress)
* What works for them and what doesn't
* To share screenshots of views they currently use (if possible).
We should a variety of different _types_ of usages in the same: for example, a large public organisations, a small NGO, a mid-sized company, perhaps a scientific team...
### **Open questions**
* **Sum:** Should it be possible to sum Reported progress?
* \[PS: Yes. Why not?\]
* **Reported and/or Calculated:** Should it be possible to use both Reported progress and Calculated progress (% progress) at the same time? Or should use users have to pick one or the other?
### Figma
https://www.figma.com/file/znrocQvFNLb5jXRXNo7oeD/Progress-estimation?type=design&node-id=1010-7036&mode=design