Skip to Main Content
Status Unlikely to implement
Categories Releases
Created by Daniel Pokrývka
Created on Aug 12, 2018

Innovate capacity planning and release planning - plan features to multiple releases

CAPACITY PLANNING/TRACKING/REVIEW
There is a very frustrating situation when capacity planning done in the beginning of the release can not be persisted by the end of the release when you have undelivered features and have to move them to another release. This breaks the capacity allocation and tracking/review capability. Splitting the feature thus is the only option and it is not always a preferred choice. 

I would like to propose a new complexity of the relationship between releases and features by implementing N:N relationship with ability to persist time tracking attributes on particular relation, also, quite importantly, other attributes - status, assignee.

One of the many implications - features will have ability to be planned within multiple releases.

One of the perspectives for grooming - "versioning of the feature". It would be interesting to combine it with "master feature".

P.S. relases are really just time-frames. Prior execution, they represent "a plan", during execution they represent "what is worked on" and when the release window ends, they represent "what is delivered". Each of those 3 categories might be represented by not always the same features. Especially first and last one.

  • ADMIN RESPONSE
    Jul 22, 2022

    Thank you for your idea. Master features can span multiple releases in that the features they contain can be from multiple releases. In a situation where you have a feature that includes work across multiple releases, we would recommend using master features to represent the larger feature to deliver. You can then create separate features representing the work to be done in each release -- all related to the main master feature.

    Given the availability of master features, we do not have plans to allow a feature to span multiple releases. We hope you can understand.

  • Attach files
  • Daniel Pokrývka
    Reply
    |
    Mar 8, 2019

    I can understand this. Your response has reached me (my bad) just now and that is after I have proposed this model using master features myself.

    BUT: The trouble is not when you can upfront decide and plan, that a master feature will have to have three features that will be planned into release A, B and C, and MF remains in release F when it is delivered.

    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 < ROE. That when release 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. Thus eliminating chance to look at several releases back and learn from past mistakes. Thus not exactly contributing to ability to "inspect and adapt". Thus effectively making life of AHA evangelists like me a bit complicated when I have to justify to agile coaches, scrum masters and others that "it does not matter".

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