Our engineers do their dev work at the Requirement level in Aha!. Capacity Reporting would only benefit us if we could track time/points associated with Requirements (not Features) to accurately do resource planning of our engineers.
Release time frame | 6 months |
Agreement with all the other comments here. Requirements to Jira Stories. Stories get assigned to resources. So we cannot see true capacity plan at the Feature level.
We use a mix where some features are estimated at the Feature level and others are estimated at the requirements level.
Requirements are allocated to different developers in within a Feature meaning we cannot see a capacity report at developer level which is quite a limitation for us
Also, When the estimating at requirements level for the story is turned on (which we get from Jira integration) there is no ability to enter an estimate at the Story level it show shows time remaining so we are in a catch 22 scenario.
To accurately track the capacity of developers, being able to also track the estimates from the tasks in JIRA, roll the total to requirements and then to the feature. So along with this view at a requirement level, also being able to include the breakdown by to-do's (tasks), will be awesome.
I have to agree with adding this Feature. Since we link Requirements to Jira Stories, this is really necessary for us to be able to use Aha! for capacity planning in any useful sense. Our Features are generally assigned to the Product Owner or Product Manager, so having capacity reporting at the Feature level isn't useful for us. (Our agile coaches are pushing to move to Jira Align for this Feature, so if this were added it would bolster our argument to retain Aha! as our primary roadmap planning tool.)
Hi
Love your capacity report!
BUT!
Currently we assign a Feature to a Team and Requirements to Individuals inside that team.
So, not really useful yet, but would be brilliant if it could be based on Requirements instead.
Thank you
yes, very good point and very relevant is engineers are working on requirements across various product features, which commonly happens in my case