Only time committed to a feature between a release start and end date should be subtracted from the release capacity.

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?).

 

  • Alan Kell
  • Feb 3 2017
  • Likely to implement
Release time frame
  • Attach files
  • Patsy Jones commented
    February 3, 2017 21:37

    This would make life so much easier when planning releases!