Burndown chart of open issues count within a milestone.
Only show a burndown chart on the milestone page, if the associated milestone has a start date and a due date. If the milestone does not have both, do not show anything.
x-axis should reflect the milestone period.
y-axis should be open issues count over that time period.
If feasible, the chart should be displayed in mobile and tablet views too. Its behavior will have to be evaluated during implementation.
The empty state (feature discovery) should be shown on milestone pages if those milestones don't have a start date and a due date. It should be shown until the user clicks the dismiss button (x icon) OR the “Add start and due date” button. From then on, this information box will no longer appear for that user on any milestone.
Algorithm
Assume all dates/times are with "day" granularity.
Assume each issue has closed_at, and it gets updated every time the issue is closed.
Suppose I am looking at a given day, call it d, and that milestone-start-date <= d <= milestone-end-date, which we only care about for the purpose of generating the chart. Note that d has no relation to now. We can be looking at milestones in the past, present, or future.
Suppose I am looking at a given issue i that has the associated milestone with it. I only care about issues with this milestone.
Consider these scenarios:
If d > i.closed_at && i.state(now)==closed , then i was necessarily closed on i.closed_at. So do not count/weight it in the burndown chart as an open issue.
If d > i.closed_at && i.state(now)==open, then assumei was opened on i.closed_at + 1 day. So do count/weight it.
If d == i.closed_at, then assumei was closed for that whole day of d. So do not count/weight it.
If d < i.closed_at, then assumei was open on d. So do count/weight it.
Stretch goals
Show an informative tooltip when hovering the chart with the number of open issues for that date (e.g. 22 open issues • Sep 16, 2016).
The system should generate tick marks on the x-axis and put in dates automatically when the chart loads. We can assume that users are sensible and their milestones are not ridiculous, i.e. designing/implementing for milestones that are at least a few days and go up to several months. The chart should not break if it is out of this range, but it doesn't have to look good in those extreme cases.
The system should generate tick marks on the y-axis automatically based on the data that makes sense, again for reasonable scenarios. Don't have to worry if somebody decides to put in 1000 issues for a milestone.
This page may contain information related to upcoming products, features and functionality.
It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes.
Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
@JobV back to the charts, I don't think ideal burn-down visualisation can bring any value in our working environment, as somehow we need to consider scope creep, am I correct? Plus another question is if we're going to show forecast in case scope creep is considered?
@skyruler could you create a mockup for this? For the first iteration, let's keep it simple and make it a basic burndown chart. Happy to discuss in detail.
If we can visualize this on the milestone page (this will be part of an EE option, so not by default) that'd be awesome, as this is where it belongs.
@skyruler I think we would already benefit from having a very basic burndown, just showing nr of issues vs. completed over time vs. the deadline, like I described in the issue description.
Right now, there is no good visualization of progress over a milestone vs. the time to the deadline. I.e. I can't see whether we're on track on not (not accounting for the issues as described by @creamzy).
So, let's start with something simple that is just the burndown of issues:
X-axis: time from first issue closed - 1 day, to deadline of the milestone
Y-axis: nr of issues
line A: linear decreasing line from X=0 to X=max to Y=0 at X=max (a diagonal line going to the bottom left)
line B: issues open at time X
Later we can add more features to the graphs, but we should start as simple as possible.
Very interested if this will be included in future versions. Issue boards in combination with Burndown charts create a very nice scrum tool. Right now we're using an external tool that parses issue contents for custom tags ("workload: 8") via the API and builds the graphs.
Lots of companies love burndown charts. :) @JobV Should we consider this as an EE-only feature? Small companies can certainly do planning and issue tracking without it, although it is part of basic "scrum".
@markpundsack EE-only, yes. In larger organisations this is often a requirement, whereas (as you say) this is usually less important in smaller teams that have no intention to grow larger (see our note on potential user base here: https://about.gitlab.com/about/#stewardship).
@JobV We are a very small team with only four developers. Currently, we are using JIRA+Agile (https://confluence.atlassian.com/agile/jira-agile-user-s-guide/using-a-board/using-reports/viewing-the-burndown-chart) and in our case, for a four week sprint the burndown chart is the only chart we use. It tells us everything we need to know, remaining days, time spend, time needed. So we see early if we have to remove features or if we even can add some. Without the chart there wouldn't be any way to see where we stand.
I see you are not time or story point based, but I just wanted to mention how important this feature is, even for small teams. Sincerely
Just to add an additional comment - we are a Team of 10 developers and were considering moving to Jira as we really wanted to get the agile features.
Issue board solved a lot, but burndown charts are still missing (we're rolling our own external tool for this). For us this is much more interesting than Cycle Analytics that you are releasing in 8.13.
I think the features would help any team of developers looking for agile-friendly issue tracker (competitors being Pivotal and Jira here).
I agree, issue weight and burndown chart are critical for a proper agile setup in gitlab, even for the small teams. I use issue weight in my gitlab.com EE repo for my team of four.
I understand the commercial point of view considering issue weight is an EE exclusive feature, but I still believe that any agile team, big or small, would benefit from this.
I feel if there's a feature then to give a WOW effect there should also be a way to graphically analyze the feature to understand the importance the feature adds. As issue weight is already present, graphs like burn down chart would add more value towards it and be more used by small/large organizations.
There could be multiple possible graphs that can be added with issue weight/date, a basic can be given to CE and more in-depth graphs can be added in EE.
Kanban charts would be great too. Some of these should fall out pretty easily from the data that you already have within issues as you record a timestamp of when a label (corresponding to a board list) has changed. So graphs like cumulative flow and cycle time (and process control chart). (not sure if your cycle analytics will already cover the cycle time graph? - will it track changes from list to list across a board?)
This is on your roadmap for EE only- could it also appear in CE and .com as this is a feature useful for 1-5 users and more (think your target with EE was 100+)
I think this is more relevant for teams that with more than 100 potential users. That doesn't invalide its usage for smaller teams, but a smaller team is much less likely to need this feature. Read more about it on our stewardship page.
@yunti can you link an example of a kanban chart? maybe create a separate issue for that.
@JobV thanks for the feedback kanban chart issue raised here: #1087 (closed)
I didn't realise .com runs EE. Sorry for my ignorance between the products and how you target them. Thanks for the link.
Here is a proposal for integrating a burndown chart in each milestone page. The “Issues > Milestones” sub-navigation is currently missing when you visit a milestone page, but it will probably be added according to https://gitlab.com/gitlab-org/gitlab-ce/issues/22986, so I already included it in this proposal.
While making room for the burndown chart, I re-organized the basic details of the milestone to mimic the sidebar seen on Commits and MRs. I'm not a fan of the current “Edit” links, so I restyled them (uppercase, smaller font size) to accentuate the difference between information and actions.
I tried to make the chart as simple and basic as possible, but feel free to point out things that can be simplified or removed.
Also, if you think this should be on a separate page/screen/section/tab, please suggest.
I only thought about this after committing, but I'd probably change the “Issues” dropdown into a button group with “Issues | Issue weight”, since we'll only have two options for now.
Last year I created a tool that plugs into redmine API and generates burndown charts, so that any member can get useful feedbacks from the sprint status.
Let me share one of the features it has, I hope this can give you some interesting ideas.
Have we planned the sprint with a realistic size compared to the team velocity? --> Initial blue bar vs baseline burndown blue line
Are we seeing any scope creep that requires a scope/schedule action from the product owner? --> Blue and yellow bars (per day)
Are we on track to meet the deadline? --> gray dotted line based on the team velocity
Have the sprint features been approved by the QA team? --> the bar becomes green (not appearing in the screenshot), but this one is quite difficult to make it fit all needs
The immediate information that members can get here are:
Scope was oversized even before the sprint started. This is obviously the reason why deadline is not met.
PO took actions to reduce the scope afterwards, but apparently not enough (did not leave enough slack time).
Sprint will be completed one day late, but the team agreed that it was acceptable (and yes, this is a mini-sprint).
There's one big but I totally forgot about: we don't have a starting date for milestones!
So your mockup shows the month minus some days, but in reality we don't have that data.
I think the easiest way without adding a starting date to milestones is to:
show the graph from TODAY until Due date if 0 issues are completed
show the graph from the moment that the first issue is completed - 1 day, until due date
Alternatively, we just add a starting date, but I haven't given that proper consideration yet.
Thanks @JobV, I'm glad that it serves its purpose (at least to get some discussion going). I also thought about the starting date, but I left that out on purpose to see what other people thought
Usually, burndown charts are used to visualize the progress of a defined scope of work during a specific timeframe. Today, you can even create milestones without a due date — something we have to think about as well since burndown charts only make sense if there's a due date.
The suggestions you gave are good food for thought. When I used Jira, burndown charts were attached to sprints (which had start and end dates) and the guideline was drawn according to the initial scope of work. If more work was included in the sprint after it began, the “guideline” would not change, only the “progress” or “remaining work” line would spike.
The way we work today is by adding issues to milestones during a period of time until we decide to close the scope. This means that issues could already be completed before the milestone scope is decided. I'm not sure how to design a burndown chart that could be useful in this situation since we are not specifically marking the “start” milestones.
show the graph from TODAY until Due date if 0 issues are completed
show the graph from the moment that the first issue is completed - 1 day, until due date
@JobV Both options sound reasonable to me but yet they fail when it comes to show that no progress has been made. For example if a sprint lasts already for one week and no issue has been closed, this would usually end up in a horizontal line in burn down charts. With your suggestions this would only shift the start date.
May I suggest that we have a date picker to select the start date next to the chart? That way we wouldn't need to store the start date and later migrate in case we want to attach it to something else than milestones (e.g. sprints).
If adding a start date into the milestones is a considerable change to the product, then it might be better to set this up as another feature.
@winniehell 's suggestion is quite interesting, the date picker allows to achieve the goal, and we can set the default to "first issue closed -1 day". Some edge cases would also need to be considered (no weight?).
In the sample I showed before, start/end milestones are mandatory, no date = no chart.
Eventually it would be nice to have a start date so that the team velocity can be measured.
@JobV Ok, sounds good. If we add the start date per https://gitlab.com/gitlab-org/gitlab-ce/issues/23704, the burndown chart is only visible with both start and end dates — correct? We don't have past velocity metrics to automagically calculate the guideline, so I guess the chart is required to have both dates.
Very nice @pedroms! Looks great. Do you have an idea for the start/end date when the sidebar is collapsed? I'm guessing we wouldn't want to duplicate the calendar icon. Maybe we show one calendar icon with Aug 22 - Oct 22 2016? This might be long with the small width though.
@tauriedavis Thanks! I was initially thinking about two icons, but your suggestion seems way better When collapsed, I think some items in the sidebar should have a smaller font-size and be truncated (e.g. milestone name on issues can be longer than “8.14” and it looks terrible). I'll post a mockup with the collapsed sidebar after more people pitch in (I'm looking at you @JobV )
Let's start with the minimum shippable and useful feature. How about just showing remaining open issue count, and ignore the weighted version for now. So we won't need the toggle button. Also we don't worry about the dotted line either as a first release. So we can get rid of the legend as well.
The on hover feature can be a stretch goal for developers. We don't absolutely need it for a first release.
The title of the chart should be something descriptive, as a general principle of UI right? (E.g. you don't see the word "Emails" in your Gmail interface.) So maybe the title can be "Open Issues". It's obviously a burndown chart. I don't need GitLab telling me that.
And so the y-axis can be titled "Count" or "Remaining" or maybe even blank?
The x-axis should not need a title. It can be blank. Because it is obviously a time axis. The chart should just automatically display a good enough granularity (whether that be weeks or days or whatever the algorithm does) and show those dates accordingly.
How about not showing the chart at all if the user is on a phone (or whatever the responsive web size is for phone as implemented). I'd rather not show anything in this case, than give a crappy experience where the chart maybe super squished, or even skewed. Ans I'm sure it makes it a lot easier to implement.
@victorwu thank you for looking at this! I agree with almost everything, which is great
Also we don't worry about the dotted line either as a first release. So we can get rid of the legend as well.
The “Guideline” is an important part of the chart because it shows how well you are progressing towards the end of the milestone. We could have a marker for the end date and remove the “Guideline” entirely, but that wouldn't help you see progress vs. time left. I haven't seen any burndown chart without it.
The on hover feature can be a stretch goal for developers. We don't absolutely need it for a first release.
Sure, I'll keep it on the designs but state on the issue description that it's a stretch goal.
And so the y-axis can be titled "Count" or "Remaining" or maybe even blank? […] The x-axis should not need a title. It can be blank. Because it is obviously a time axis.
“Remaining” for the y-axis and no title for the x-axis
I'm worried about the guideline being confusing, since it's just a straight line without any specific annotated information except for the word "guideline". But I do agree it's a typical design in the context of burndown charts. Right now it's just linear line, and doesn't take into account of previous velocity of milestones, etc. (which is something many tools like this have, that we should think about soon). So the potential confusion is a user seeing it and saying, "This chart tells me that I should be able to finish the milestone right on time, based on how I performed in the past?", when we don't have that advanced functionality just yet.
I'm just primarily worried about shipping quickly. Let's go with your design and we can discuss further as developers get their hands on it and tell us something would take more or less time.
As for the legend itself, "Guideline" is great for this release. In future releases, we might want to say "Projected" or "Estimated" and that dotted line would be very smart. Should "Progress" be just "Open Issues" instead? And in the hover label, that "/" looks weird. What do you think? And for consistency, what's our rule on capitalizing words in labels?
@pedroms : What do you think about mobile/tablet views? I'm tempted to say let's not include any chart if the screen size is too small, because this can get messy really quick with more elements added later in future releases.
@victorwu I researched the guideline usage and labeling before deciding upon this. Many other implementations of burndown charts use “Ideal burndown” , “Ideal work remaining” or something similar, which points to the interpretation of “Oh, I should follow that line because that's the ideal!”. But this point of view is incorrect. What we are communicating here with “Guideline” is: this line helps you understand the relationship between your total amount of work and the date it must be completed in. Essentially, it translates what you have planned for the milestone. I'm also open to change it to read “Planned” (in that case, the “Progress” would be better as “Actual”).
If in the future we add a line that forecasts the progress based on previous results, take a look at these two examples that predict when the scope will be completed base on the current scope velocity:
Regarding mobile/tablet views, I understand your concerns. I'm also hesitant but willing to give it a go and see how it scales. It's a pretty simple visualization, and even with more elements in the future, we have to try and keep it as simple as possible.
Thanks @pedroms for the context and pushing forward with this. I'm probably getting into analysis paralysis. Let's just ship something and get some feedback. I'm excited about this feature and want to see how people use it and the feedback we get before we dig further. I'll only say I like "Planned" + "Actual".
I'll defer to you what you think makes sense. Do you want to make a final design decision and update the description with the finalized mock?
Edited the description with current designs, link to design specs and added a stretch goal for the informative tooltip. /cc @victorwu
@hazelyang can you take a look at the illustration in the Empty state (feature discovery) design? You have better illustration skills and I'd like to make sure everything is aligned. I looked at the existing illustration for cycle analytics feature. Please feel free to suggest a different approach, this is only an example!
@hazelyang Looks great! Thank you for pitching in. I've updated the issue description with the new illustration.
@connorshea I think it will look ok on mobile because it's a simple visualization. It's not something you will actively work on but rather an indication of how things are progressing. Nonetheless, it has to be evaluated during implementation. I've updated the description accordingly. Thank you for questioning
@jschatz1 currently this is planned for 8.15, but I suspect this is a lot of work on the frontend, considering we want something better than the current graphs we have. Any insights, suggestions?
Loading the issue board with the burn down chart can be quite expensive. The way the issue boards are now, they are not exactly modular (well they are, but not sure how flexible they can be).
@smcgivern What do you think of backend implications here?
Also to make this all one API call would be ideal but heavy as well (scoping can be an issue for one call).
For example:
burndown?merge_requests=all
Will need to paginate here on the page without refresh to avoid another Chart call to be made
1. Vue instead of HAML (MR view has not been written in Vue yet)
This will add ~"technical debt"
burndown?participants=all (might need to paginate)
burndown?labels=all
etc!
As it stands we would make two separate API calls I think (Chart Data, Issue Boards) on page load.
Just logging some info down!
MVP?
Maybe just have buttons that open a new tab for scoped issues/labels/MR's and have the burndown chat be the main focus?
That could prove to be a good first MVP (possibly not as well haha)
I am mostly worried about ~"technical debt" (having two ways of rendering the same thing)
@selfup am I missing something not mentioned above? I can't see anything to do with issue boards? Milestones already have these draggable columns for issues & merge requests, is that what you are referring to?
From the charts, my assumption is that we are storing the counts per-day separately from the current count of issues. So that when a chart is requested, we're not trying to figure out what status every issue in the milestone had on historical dates, but just showing pre-computed counts. Is that right @victorwu?
@pedroms : Let's work on this even before the sidebar replacement of the summary (https://gitlab.com/gitlab-org/gitlab-ce/issues/23674). We can have the burn down chart just sit on top of all the summary content, or below it. I don't want to delay this further for something like the sidebar, which is a much more minor impact feature in comparison.
@smcgivern: We don't have to worry about the super edgy cases where an issue closes and re-opens several times during a milestone. We can tweak the definitions depending on what's feasible.
Here's my guess: When the chart is requested, look at all the issues in that milestone. Look at all the open issues in that milestone. That contributes to the open count of issues right now. Look at all the closed issues. Look at when they were closed (I assume you would use last_updated?). And re-create history (counts and weighted counts) by looking at those timestamps. To me, anything equivalent (pre-computing values, etc.) to that logic is most natural for a burndown chart. @pedroms please confirm if that's your design thinking.
Do you keep change history of each attribute of the issue? (size, status, milestone)
When I implemented my burndown chart, I had to:
go back in time to the start date, fetch all issues that had been in the milestone at least once
get each issue attribute at the point in time
calculate the total scope and burnt points for this point in time
go to the next date until today or the end of the milestone
It really depends on how easy it is to retrieve the status of a sprint (size, burnt point, etc) at a specific date. If you have to recalculate them, then it will take some seconds to generate.
Thanks @jvasseur for bringing that up. I think that's an edge case we don't have to deal with now.
We can just take the current state (all issues in the milestone) and go from there. If an issue is added or removed from a milestone, we don't have to consider that inconsistency. That is, we are just solving for the happy path where the issues within a milestone doesn't change during the milestone itself, so your burn down chart looks relatively sane over time.
@smcgivern : Again, this is my assumption based on what is easy to build. We can chat further if this is not the case.
@victorwu an issue can (and often is) updated after its status changes. I don't think that is accurate enough. (For instance, I think referring to an issue will bump the updated-at.)
@jvasseur brings up some good points. We don't have the ability to rewind time like that, as we're not using an immutable data store. That's why I suggested storing the counts (but not the issue IDs themselves) per day, so that they will be accurate.
If you have an update log, then you can go back to the past (yeah, changing back attributes one by one for each log from oldest to nearest to the date you are look for).
This is why I said that this would take seconds to generate a burndown chart from this data structure.
But, you could use a similar strategy to store the counts for each day when user access the page for the first time, and then avoid redoing this heavy process for next accesses.
Advantage: any old milestone could have a burndown chart.
Inconvenient: first time access would take time. And you would probably prefer to not count issues that where in the milestone at some point, but not at the current time. This is quite a messy hack to workaround unadapted data structure.
Considering that you have a data store similar to above (did not check the models), then I would rather suggest to trigger an update for a new burndown dataset every time an issue is update.
Advantage: rather light in term of computing load, and almost invisible to the end user.
Inconvenient: past milestones would not have the burndown generated/displayed.
Okay @smcgivern that makes sense. So essentially some way to generate and store the aggregated data at some time frequency (daily or otherwise). That's totally fine and definitely accurate enough (if not actually most accurate, depending on your definition of truth here). I can envision a weird scenario if say in one day, somebody decides to add a bunch of issues to a milestone, and then the next day, they remove those issues. So in the chart you would have this weird spike that goes up, even though regular burn down charts are monotonically decreasing (non increasing) usually. But again, that's totally okay imo, because we are designing for the happy path case.
I can envision a weird scenario if say in one day, somebody decides to add a bunch of issues to a milestone, and then the next day, they remove those issues. So in the chart you would have this weird spike that goes up […] — @victorwu
Yes, that spike is correct if you add issues after the milestone start date. No problem with that.
tl;dr: No. @jschatz1: Yeah, it would be great if everything in GitLab is real-time. For this issue, if somebody leaves this page open on a monitor in the office, they could see things being updated day to day without browser refresh. That being said, this is a very very low priority for real-time given that use case.
Been following this thread for a while, really looking forward to burn down charts. Just an idea reading @jschatz1 and @victorwu's comments on realtime. Seeing that you're also integrating Prometheus in the upcoming versions - perhaps the burn down charts could be sent to Prometheus?
That can then be graphed real time with Grafana or other graph backends on the companies dashboards - if changes to ticket state / backlog of the milestone occur this can be pushed directly to Prometheus.
@pedroms : Did you dig these from your emails to reproduce? That's awesome =). Maybe someone can write a script to parse emails and re-create lost history =p.
One note about dates: The burndown chart makes sense even without start and end date set. The start date can be easily calculated automatically — min(today, first issue closed). The end date does not have to be set — then the guideline will be missing, but there can be estimate/trend displayed.
Quite often I wonder when a next version of some open-source software is going to be released and such projects often don't have a fixed roadmap. They are released when ready. But still, it is interesting to see some estimate on when the “ready” happens. Therefore the burndown chart should show such estimate.
@smcgivern First of all, I think that we should have an easy way to keep track when an issue was closed. Today, correct me if I'm wrong, but the only way to have this information is through system notes @dbalexandre closed 10 minutes ago that is a huge table. Maybe adding closed_at column on the issues or issues_metrics allow us to quick generate this chart using a SQL with a group statement since we are interested only in the number of issues closed per day between the start and end dates of a milestone. We need to take care to count only issues that are visible to the current user, what can make this query a little expensive. In this case, we can cache this data if needed and invalidate it when an issue is added/removed from milestone or closed/reopened.
@victorwu What is expected behavior when I add issues to a milestone that were closed before the milestone start date?
@dbalexandre thanks! I agree that using system notes is going to be painful. closed_at is interesting, because I've often wanted a merged_at for MRs. I didn't know about issues_metrics - that's a good idea!
@victorwu in addition to Douglas's question, what happens if I have an issue that was closed during a milestone, but wasn't on the milestone. If I later add it to the milestone, what should happen?
@dbalexandre@smcgivern : Good questions. Let me assume that we are using the closed_at attribute per issue. If that is the case, can we not keep any state with the burndown chart anymore? And just generate it on the fly each time the page is rendered? If that is the case, this is how I would model it in my brain, this being the simplest model I can think of:
Assume all dates/times are with "day" granularity.
Assume each issue has closed_at, and it gets updated every time the issue is closed.
Suppose I am looking at a given day, call it d, and that milestone-start-date <= d <= milestone-end-date, which we only care about for the purpose of generating the chart. Note that d has no relation to now. We can be looking at milestones in the past, present, or future.
Suppose I am looking at a given issue i that has the associated milestone with it. I only care about issues with this milestone.
Consider these scenarios:
If d > i.closed_at && i.state(now)==closed , then i was necessarily closed on i.closed_at. So do not count/weight it in the burndown chart as an open issue.
If d > i.closed_at && i.state(now)==open, then assumei was opened on i.closed_at + 1 day. So do count/weight it.
If d == i.closed_at, then assumei was closed for that whole day of d. So do not count/weight it.
If d < i.closed_at, then assumei was open on d. So do count/weight it.
I think this answers your questions and it is simple enough. Keeping it stateless should keep it fairly sane right? And with this model we are purposely ignoring edge scenarios where issues open and close multiple times during a milestone, because it's not worth the complexity/work to account for all of those. Just make simplifying assumptions. Open to further discussion of course.
What do you think the design should be if there are some issues that have no weights assigned? This is my proposal:
The system just looks at all the relevant issues as before.
It treats every single issue as having a weight. If no weight is actually assigned, the system just assumes the weight is 0.
All the calculations are the same. So essentially if you have a zero weight issue, it does not contribute to the burndown chart value.
I think this is a good proposal because:
It probably makes the code implementation relatively simple. Possibly this isn't even a special case in the code if the numbers returned are generic enough?
If a team is not using weights, when they look at the cumulative-weight burn down chart, they'll see a flat line, and it's obvious to them why it's a flat line.
If a team is using weights, and forgot to put a weight on a specific issue, it won't be accounted for. They might discover that later, and fix it. And we can build features later on to alert them to the fact they probably forgot to assign a weight.
@pedroms how should we be handling milestone pages like /dashboard/milestones/xxxx and /groups/gitlab-org/milestones/xxxx? Will these have burndown charts available as well?
These present a slightly more complicated situation because the underlying projects could all have different start or due dates. Perhaps we only show the burndown chart if all sub-projects contain milestones with the same dates? If so, how would we convey this requirement in the help box? We can't simply link to the "edit" page to let them add a start/end date because it may need to be done in multiple places.
@mikegreiling@pedroms : Thanks for checking with those cases. Let's leave those out for those iterations. For those pages, we simply don't have any burndown charts. Thanks!
Mike Greilingmarked the checklist item Show an informative tooltip when hovering the chart with the number of open issues for that date (e.g. 22 open issues • Sep 16, 2016). as completed
marked the checklist item Show an informative tooltip when hovering the chart with the number of open issues for that date (e.g. 22 open issues • Sep 16, 2016). as completed
Mike Greilingmarked the checklist item Burndown chart with cumulative issue weight. as completed
marked the checklist item Burndown chart with cumulative issue weight. as completed
Does it ignore the due dates of the issues? It looks that way to me... I have issues due to a certain date inside my milestone but if a day passes (and the issue is still on time) the line displays 0 progress. Is this the intended behavior? If so is there a way to take into account the issues' dates? I'd like the graph to only move away from the "desired" track if the issue is delayed (or was completed earlier).
@eestein issue due dates are not taken into account because the burndown chart is associated with a milestone that has defined start and end dates. Issue due dates are currently independent from milestones, as they are a way to track issue dates individually. Milestones are used to track issue dates collectively. There's currently no way to take that into account, but feel free to create an issue with your feature request.
@pedroms thanks for your reply. My milestone has defined start and end dates as my issues inside that milestone. It might be only me, but it seems that those dates should be taken into account as well, while plotting the line...
My reasoning is:
let's say I have a milestone sprint1 that is a 5 days long and inside sprint1 I have 5 issues. The first issue's deadline is in two days, the second in 4 days and the 3rd, 4th and 5th are only due to the 5th day.
Day 1 passes by, issue 1 is not closed (it's still on time - due to the 2nd day) the graph will display:
|_________|||
That might give the wrong impression the project is delayed, when it's not. Issue 1 is only due to the 2nd day. I'd expect that line only at the end of day 2. By day 2 I'd still expect to see:
That would be a good candidate for projection line, a different line from the actual burn.
The projection line could look at each issue completion date, and then calculate the future burndown status.
However, it introduces some complexity when some tasks have target date, and some don't. Usually burndown charts don't expect to take in consideration each task's target date, and Agile practices would usually say that if your burndown chart keeps straight for a while, then it is time to break down into smaller tasks.
@jvasseur I agree with the added complexity, for that case not having the due date on an issue would mean it's not gonna be taken into account in this projection line, or it's not gonna be generated at all. It makes sense, I'm not trying to add extra complexity here... and if you don't add the due dates for every single issue you have, you obviously cannot expect to see the projection line.