At the moment it appears that the time committed on a feature, plus the remaining estimated time on the feature are subtracted from a release capacity to work out how many features the release can hold. This is the case regardless of when a time is committed to a feature. This becomes an issue if you move a feature from release 1 to release 2 with time committed as the feature wasn’t complete during release 1.
The time committed in release 1 plus the now adjusted remaining time estimate count towards the feature size in release 2 - which isn’t right.
I would expect only time committed to a feature between a release start and end date to be subtracted from the release capacity.
For example - Feature 1 (initial estimate of 10 hours) doesn’t get completed during Release 1 but has 20 hours committed to it. When Release 1 ships Feature 1 is moved to Release 2 and the remaining work estimate is changed to 5 hours. Release 2 has a capacity of 15 hours and contains Feature 2 which is estimated at 10 hours.
The capacity line for for release 2 suggests that Feature 2 won’t happen because it is taking Feature 1 as being 25 hours (more then Release 2’s capacity) whereas the remaining 5 hours of Feature 1 and the 10 hours of Feature 2 should both be achievable in the 15 hour capacity in release 2.
This idea is to have the text on bold be true to allow capacity to be affected in a way that handles time committed to a feature in a previous release.
Until then, committing time to tasks and using capacities in releases don’t work together (unless I am missing something?).
|Release time frame|