RELATED IDEAS
Capacity management cross releases
The trouble is that when you plan a feature into release R1 with capacity C1, it is not a super rare situation when after execution of that release (when collecting data from requirements as "work done" and "remaining effort"), the original estimate of the feature F1 being FOE <= C1, you end up with remaining estimate having FOE <= C1 < (FOE+RE). Then when a release R1 is being wrapped up and next release R2 is being planned, you have to either
1) move feature F1 to release R2, which aha ALLOWS. But if you do that, tracked workload data like original estimate, remaining estimate and work done are not anymore tracked in R1 and R1 capacity evaluation is thus damaged and retrospective information is destroyed => eliminating chance to look at several releases back and learn from past mistakes. Thus not exactly contributing to ability to "inspect and adapt" principle and effectively making life of AHA evangelists like me a bit more complicated when I have to justify to agile coaches, scrum masters and others that "it does not matter". It does matter indeed if you mean to use capacity aspects of AHA for more than super simple planning (e.g. capacity reporting or tracking).
or 2) after having to admin that this actually "matters". I need to keep feature F1 in release R1 so that I do not destroy R1 capacity tracking quality. I have to create feature F2 in Release R2 by copying and asigning new original estimate (which is fine, based on learning a bit by delivering F1 we can even use this opportunity to have better estimate for the leftover work on originally planned F1). But what about status of feature F1? I can not exactly keep it as "Shipped" if it was not actually deployed and I need to adjust feature workflow and add status "Unfinished" or "To be continued, stay tuned". OR I actually can put it into "Shipped" if the feature was indeed representing some kind of value and was indeed deployed as partial original scope of F1. Argument that I should have created F1 into R1 and F2 into R2 in first place when planning R1, is IMHO not valid.. as you simply might not know at that point and you might believe that F1 is the only F as F1OE<=C1. This is actually the "method" I have to be using.. but again .. some people using AHA are not so fond of thinking in letters and acronyms when I am explaining these concepts and they do not get it.. some agile coaches and senior managers coming from PM background say "if only we had simple gant chart.. so much manual work saved" .. again, "or 2" is solving the problem, but it is not helping to get me to a place where the whole company considers aha as "golden source" for product management and that makes me frustrated to a point that I get to a keyboard on Friday/Saturday at half past midnight after hard work week and write this comment with headache and impaired vision. Not mentioning work-life balance disruption caused by all these things when I try to go extra megamile with AHA evangelism...
So summary
1) capacity planning works well (at least for "time"..)
2) capacity tracking works semi-well (some issues with JIRA 2.0 integrations are making my journey to full aha adoption company wide a little bumpy...)
3) capacity review and closure of the release is lacking full feature journey design in its core and even promotes exploting the absence of solution by allowing easy drag and drop moves of F1 from R1 to R2. We have also case where such a feature goes to R3. And can get lost in parking lot for a while. Multiply this problem by 10+ products, 20+ product owners/managers, 45+ (normal ratio in our perfect agile world) of other managers and project-minded people, and ...
yes.. I understand, that I can use master feature.. and now I have to. But I hope I managed to demonstrate that design of capacity management is not complete and implemented in a usable way in "normal" scenarious when someone has real ambition to use it in enterprise environments with multiple business domains and IT components, multiple teams dislocated into multiple IT offices accross regions and continents.
P.S. I am sorry if I overstepped here a little and somewhere been less than "politically correct". But I am doing my best to make it all work and can not get my head around these things yet (after 2 years of gradually using aha more and more...)
P.S. 2 - as always.. thanks for your loveable product. It makes me happy. But sometimes I feel pain too :-).Why is it useful, who would benefit from it, how should it work?
1) move feature F1 to release R2, which aha ALLOWS. But if you do that, tracked workload data like original estimate, remaining estimate and work done are not anymore tracked in R1 and R1 capacity evaluation is thus damaged and retrospective information is destroyed => eliminating chance to look at several releases back and learn from past mistakes. Thus not exactly contributing to ability to "inspect and adapt" principle and effectively making life of AHA evangelists like me a bit more complicated when I have to justify to agile coaches, scrum masters and others that "it does not matter". It does matter indeed if you mean to use capacity aspects of AHA for more than super simple planning (e.g. capacity reporting or tracking).
or 2) after having to admin that this actually "matters". I need to keep feature F1 in release R1 so that I do not destroy R1 capacity tracking quality. I have to create feature F2 in Release R2 by copying and asigning new original estimate (which is fine, based on learning a bit by delivering F1 we can even use this opportunity to have better estimate for the leftover work on originally planned F1). But what about status of feature F1? I can not exactly keep it as "Shipped" if it was not actually deployed and I need to adjust feature workflow and add status "Unfinished" or "To be continued, stay tuned". OR I actually can put it into "Shipped" if the feature was indeed representing some kind of value and was indeed deployed as partial original scope of F1. Argument that I should have created F1 into R1 and F2 into R2 in first place when planning R1, is IMHO not valid.. as you simply might not know at that point and you might believe that F1 is the only F as F1OE<=C1. This is actually the "method" I have to be using.. but again .. some people using AHA are not so fond of thinking in letters and acronyms when I am explaining these concepts and they do not get it.. some agile coaches and senior managers coming from PM background say "if only we had simple gant chart.. so much manual work saved" .. again, "or 2" is solving the problem, but it is not helping to get me to a place where the whole company considers aha as "golden source" for product management and that makes me frustrated to a point that I get to a keyboard on Friday/Saturday at half past midnight after hard work week and write this comment with headache and impaired vision. Not mentioning work-life balance disruption caused by all these things when I try to go extra megamile with AHA evangelism...
So summary
1) capacity planning works well (at least for "time"..)
2) capacity tracking works semi-well (some issues with JIRA 2.0 integrations are making my journey to full aha adoption company wide a little bumpy...)
3) capacity review and closure of the release is lacking full feature journey design in its core and even promotes exploting the absence of solution by allowing easy drag and drop moves of F1 from R1 to R2. We have also case where such a feature goes to R3. And can get lost in parking lot for a while. Multiply this problem by 10+ products, 20+ product owners/managers, 45+ (normal ratio in our perfect agile world) of other managers and project-minded people, and ...
yes.. I understand, that I can use master feature.. and now I have to. But I hope I managed to demonstrate that design of capacity management is not complete and implemented in a usable way in "normal" scenarious when someone has real ambition to use it in enterprise environments with multiple business domains and IT components, multiple teams dislocated into multiple IT offices accross regions and continents.
P.S. I am sorry if I overstepped here a little and somewhere been less than "politically correct". But I am doing my best to make it all work and can not get my head around these things yet (after 2 years of gradually using aha more and more...)
P.S. 2 - as always.. thanks for your loveable product. It makes me happy. But sometimes I feel pain too :-).Why is it useful, who would benefit from it, how should it work?
6
MERGED
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 i...
1
Future consideration
Capacity by quarter could be achieved by quarterly release.. but I guess this is not an option for you, Gale. I think that a multiple-scenario solution could really be a capacity cross releases (maybe a capacity on master release?) that would show you remaining capacity for next releases.. just an idea.
Another little hack that could help could be a capacity consumption tied to work date, so that when you move feature with work done from release1 to release2, the work done would be still related to release1 if it falls into the same timeframe. However, I think it could create some unfortunate corner cases.. if the unfinished features got moved to release2 and some business logic behind would interpret which is the previous release1.
.. so I am getting back to the idea of some finetuning of capacity management when feature is stretching over 2+ releases. Maybe some function to split/move feature to next release that would make sure that a new feature with a remaining scope is created .. again, needs some thinking through.
It would also be very useful to be able to see Feature board by Quarter with the Capacity by quarter