Hi there -
Id like to look at all epics and user stories for a release in a hierarchical view. It should display all stories with the epic it belongs to and it should be in prioritized order. Ideally I would be able to collapse/expand stories for each epic. E.g.:
Does such a gadget or view exist?
Thanks - Ton
I put together an extension called Agile Docs which does exactly this.
It lets you view and interact with all your projects and releases in an expandable nested tree list like a google doc. It looks like this:
Also gives Epic progress reports based on the story points completed in your Epics.
I'm sorry, but as interesting as this looks....$1/user/month for a reasonable size org is unreasonable. Unless it were possible to license lock to limited number of folks (For example, this is something Product Owners and/or Scrum Master's would use, but not the vast majority of users).
It looks nice, but $2400/yr when perhaps a tenth of the users in a 200 user group would use this is just unjustifiable to management.
Thank you Marcello. I understand but I need a way of planning capacity at the start of the sprint and since 1 story can be worked on by more than 1 resource we break the story down into sub tasks. If story points are only allocated at a story level it looks like a developer (assignee) is over allocated but he/she might not be. It has less to do with the this add in and was more for understanding from screenshots I've seen for Agile docs
@Edmond Victor Have you considered that the decomposition of a story is really the domain of the team, and not a managers to manage? I don't know you, and I don't mean to tell you how to do what you do.
The "allocation" of a developer to a story is an agile anti-pattern. Unless your developers are all working "piece meal", where your billables are on the basis of actual "piece work" then what you're facing is disparity between an "how to bill for an agile team" and "how we've structured our teams to be billed from".
The former which is as I said an anti-pattern for agile teams, the other is a bit of room yet for applying a more holistic billing approach to the work product released from a team.
Teams do not estimate to bill from. They estimate to understand the relative complexity of the work involved so they can gauge different parts of a potential plan and use that understanding to build the plan from. The fact that you can use "points" to bill against is just a metaphorical concept being applied to a concrete problem via indirection.
I'm not telling you WHAT to do, just sharing that if your aim is to support a team to BE agile, the approach you're taking may not result in what you're aiming for.
Marcelo, I appreciate your inputs but we are going a down a different discussion here. Yes the team do their own decomposition and our capacity issue is not related to billing at all. It is simply related to planning and making sure that we put the correct types of work in the sprint so that everyone is contributing to the outcome of the sprint. Data Engineers cannot develop and developers' skills are diverse. Some do HANA, some SQL and others BW. When planning I need to make sure that the correct mixture of work makes it into the sprint.
Thank you again for your comments
You're welcome @Edmond Victor. My comments were based on as much context are your comments provided. That being said...
"I need to make sure the correct mixture of work makes it into the Sprint".
That statement alone tells me there's some other anti-pattern at work, and that may be contributing to the desire to decompose the work they way you're describing.
The "Story point estimate" field is available on sub-tasks by default when you create a new next-gen scrum project.
If you want to add the "Story points" field to sub-tasks on an existing classic project, you need to configure the custom fields and screens of the sub-task issuetype.
There is good step by step instructions on how to do this in this post
In terms of how it works in Agile Docs, if a Story has a story point estimate, that is what is used to sum up to the Epic. if it doesn't, it checks if the sub-tasks have a story point estimate and rolls that up to the Story, then the Epic. So if you want your team to break down a Story into sub-tasks and estimate those, that is completely fine.
Hope that helps!
You might want to try out the server addon we have built just of this purpose.
It will provide you the below features
When to use CSV importer When managing your processes in Jira, there are many occasions where you need to create a lot of tasks. Creating them one by one will cost you a lot of time and effort and i...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event