2

I have a team of developers that are building and maintaining a web application for our business. We use JIRA Agile to organize development items, plan sprints, track issues etc. One team works on the whole web application, though the application itself is divided into three different modules(Currently we just use the label field for this).

The sprint burndown is an excellent tool for measuring our short term progress, however I would like to track our long term projects.

Would it be possible to get three separate burndowns corresponding to the entire backlogs of each product (unrelated to the sprint progress). The purpose of this would be to get a guestimate for the final date that each module will be delivered.

Hope that makes sense.

I'm open to changing the JIRA structure as long as everything stays under a single project.

Improve this question

5 Answers 5

Reset to default
2

To see the progress beyond sprints you could either use epics or milestones / releases. Both enables you to see how much work - measured by story points - has been done / have to be done.

Using story points and different teams might let you run into problems due to the fact that story points / estimates are individual per team. You can compare burn downs of different teams just if they have a continuous burn down and if they reach their planned points.

The initial idea of the burn down is to get a feeling of realistic estimates for future sprints. Usually, if you don't have a well harmonized team, you will experience adaption in the estimates in the beginning of the project until the team finds it's way.

Improve this answer
3

I have worked in organizations, that deliver a single product, but have multiple teams working on different components of the product. We setup our JIRA as such:

  1. Project = Product. In your case, this would be your Web Application
  2. Setup Components for each team. I would imagine you have an API team, a UI Team etc. In this case, you would have a UI Component and an API Component part of the Project.
  3. You can view the burn down/issues related to the Components only if you want to get granular. If you want to see an aggregate view, you can view the Project, which will combine all of the statistics of each Component.
Improve this answer
1

You can create a "Superboard" that pulls in everything with a certain tag and then only use its reporting function.

Atlassian is actually pretty good at their customer support. So I would encourage you to reach out to them. Here is where they answer this question in more detail.

https://answers.atlassian.com/questions/192039/epic-burndown-charts

Improve this answer
1

I would recommend using the native version logic in JIRA to fulfill this visibility need.

I.e. each issue (feature, bug fix etc) will be associated with a fix version.

Your fix versions might be

  • "K Module, 1.1"
  • "L Module 1.1"
  • "M Module 1.1"

This will allow you to view burndowns for each fix version.

More on Versions here:

https://confluence.atlassian.com/display/JIRA/Managing+Versions

Improve this answer
0

I would use epics they can be broken down on the jira agile board and you can also use themes and features

Improve this answer
2
  • 1
    Hi, could you explain a bit more, how those task-types help to solve the problem.
    – Tob
    Commented Sep 12, 2015 at 17:49
  • Sure! If you look at the jira agile reporting tab (3) you have epic and release burndowns you can use these to track non sprint related burndown and do projections. I hope this clarifies what I was trying to say sorry for being vague :)
    – ashga
    Commented Sep 14, 2015 at 12:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.