We estimate the tasks inside of a story, so we would like to see the story points to get burned with the tasks instead of waiting for the whole story to be completed. Is there any way of doing this? Thanks, everyone!
To expand on that, this is almost always happening because someone isn't satisfied with the evident pace of progress. Maybe stories are all too big (the burndown takes too long to show progress) or someone wants to see progress too frequently ("why didn't any points go down today?").
I'd be curious why someone has so little confidence in the team's historical velocity to feel the need to micromanage progress like this. Getting Jira to do something more complicated doesn't sound like it'll solve the core problem here.
It's not an issue with micro-managing. The request is about giving credit for points completed by dev, even if QA was unable (other priorities, shared resources, etc.) couldn't verify it in the same sprint.
When running complex programs with shared resources in a matrix org, this happens. I still want to have the point value for the work completed.
We also track hours, but for those who track velocity, it should be accurate. Not accounting for the effort that is completed isn't accurate.
I'd like the option to count the points for the tasks completed, even if the Story didn't close. Else, the points are inaccurate (and what's the value in that?)
As Nic said, though, sub-tasks don't burn down the story points of the parent in scrum, nor in Jira. Though I am aware of the widespread use of the variation that treats story points like a progress meter that can be partially completed. The fact that story points are often defined as a measure of "effort" encourages that thinking, since it's easy to say "well 50% of the effort is done, so 50% of the points are delivered".
@Nic Brough _Adaptavist_ isn't all that new to this topic, I see, since another comment was left in a related post here: https://community.atlassian.com/t5/Jira-Software-questions/Attributing-Story-Points-for-Partially-Complete-Rollover-Stories/qaq-p/903268
I think this gets explained a lot by a lot of people in a lot of places. It's probably one of the hardest things in scrum and one of the reasons so much importance is placed on having a definition of done, since that's where you decide when story points will burn. If you don't want to wait for QA and everyone is cool with that, change "done" not to require it. It's either that or smaller stories. Or another tool.
I do think Jira could do better on telling us about progress on both the story and its subtasks. But I really don't want it to break the basics of scrum.
Scrum has very little to say about how we measure or count estimates and progress, it really only cares about "is it done, or not?". But it's very clear that something is either done or it is not.
@Joshua DeClercksaid "It's probably one of the hardest things in scrum" and I totally agree. It is hard, but the best thing to do is look at how you relate to your "customer". Please forgive my language here, but as a customer, I don't give a flying **** about how far through it you might think you are. Is it done?
If it's not done, you can not burn down. If it is, you can. Where Jira and Scrum are weak on progress reporting is exactly that - internally, you DO care how far through you are, but to the rest of the world, 1% through, 99% through - don't care, it's not done. "Done" is critical.
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