Why was it necessary to remove the burndown via task length? Please can we have it back? Please?

[pcoleman]

This question has been posed similarly previously, on numerous occasions but they received not much more than zealous and sanctimonious answers about the nature of scrum. I don't need Atlassian to teach me about scrum. What do I want is a return to looking at the burndown on a daily basis by the team when JIRA very helpfully produced a burndown that had actionable information on a constant basis. It was useful to have the burndown open when conducting the stand-up. Today: not so. Our sprints often contain few stories, estimated via story points. Story points have always been about capacity instead of accurate estimation. We do not pretend success due to task completion, equally there is nothing that gives a more accurate depiction of whether we are likely to be on target or off target than the burndown view that Atlassian used to give us. 

As it is now our burndown is horizontal for several days, over a week some times, then falls off a cliff. Horizontal. Cliff. Horizontal... it is, essentially, useless. Particularly when working with ~7 engineers in the team. The only ways to circumvent this are deeply unsatisfactory: for example, having very granular stories which if we are going to pontificate about the nature of scrum largely goes against the nature of scrum due to there then being no room for negotiation on story content if time pressures arise. Similarly we could use the hours of tasks as number of story points, but I don't wish to sacrifice our ability to consistently estimate scrum capacity because our vendor removed a feature. In fact I don't wish to have to compromise how we run our successful scrum teams because of Atlassian's thoughts on how scrum should be run. One of the core themes around scrum is that whatever the process is, it needs to work for us. And it does. Stories can be negotiated in terms of content. Stories are opened and completed in priority order. There is never significant work left open at the end of the sprint. Each story is completed, tested thoroughly and either deployed or deployable etc. Despite it being odd that a customer needs to appeal to its vendor on how agreeable their scrum practices are, despite our success in the domain, our software vendor tells us, the customer, how we need to work with scrum. We simply want to be even more successful by retrieving insight we used to get on the rate of execution. The feature is fundamentally useful, its removal, according to the answers given here, is dogmatic. Why punish your customers for your opinions on scrum? You don't want to evaluate your rate of success based on task length? Great, don't. Why feel it necessary to stop me from seeing my data displayed how I want to see it? Your assumptions on how I interpret that data are simply that: assumptions. 

Given the frequency that this has been raised, that this is a feature that used to exist, is there no room for negotiation here? Providing visibility into task completion does not predicate that the completion of tasks is defined as success. What it is, is a proxy that provides valuable insight into the likelihood of completing what has been estimated. I find it bizarre that a customer feels the need to appeal to their vendor on how they internally operate. A compromise would, for example, be defaulting to a points view (IIRC this is what used to be the case), or plotting both points and tasks on the same graph: one for success, one for rate of execution. As it is, using the points to indicate rate of execution is, forgive the unintentional pun, largely pointless. There is no daily update. Just 3 or 4 right angled triangles. The fact the burndown indicates way above the line of desired execution means nothing if that line of execution is accurate only 3 or 4 times during the sprint. It seems a strange interpretation of burndown because there is no burning down so to speak. The reason for the constant line indicating where the execution should be is so we can always cross reference where we are, with where we should be. Not possible when where should be is based off of completed story points, without subverting the nature of what a story is.

Please bring it back. Attach whatever advice regarding task completion != success that you feel the need to. Ironically, I completely agree with this, your error is in assuming that is how the burndown is interpreted. It is simply to ascertain the current rate of execution to indicate if we are likely to be caught short regarding time. And if we are then we can take appropriate action. But we don't celebrate success until the story is fully complete. The best we have right now is the Gadgetz plugin, which isn't a patch on what Atlassian used to provide. 

So for the final time: please bring it back as an (unselected) option. You don't need to teach your customers how they should be doing scrum. There's a lot of support for this feature and to assume that your customers must be interpreting agile / scrum in a certain way is a gross assumption on your part. We simply want to get an accurate proxy to the rate of execution so we can take action if needs be, if, for example, the rate of execution indicating that we are not going to be able to complete all that is estimated. Knowing at the right time allows us to, for example, remove non necessary tasks from the story, so that we trade-off task completion for story success. Not possible if we don't have the visibility regarding rate of execution. 

And finally forgive my tone somewhat. I am dismayed that an extremely valuable feature is removed from the featureset. Not for the benefit of the customer, but for dogmatic grandstanding on behalf of the vendor. It's not something i've encountered previously and hold atlassian to a higher account than that. Particularly as a number of my previous employees have decided to work there as engineers, i know the organization has better values than this. 

[Jack Brickey]

Hi @pcoleman , welcome to the Community. Please note that I have moved this to the discussion collection as it seems to better fit there. Hopefully some members with thoughts on this will chime in there. Also, you might want to share your thoughts with Atlassian via the in app Feedback link. In my experience that channel is well attended by their PMs.