Is it a configuration issue?
Looks like people have been adding/removing things in the sprint, and/or adjusting the remaining time directly. I'd recommend finding the issues that are causing the spikes and working out why they've been doing it
Thanks much, Nic.
Please eloborate on "adjusting the remaining time directly."
You can choose "adjust remaining time" in the worklogs, and/or edit the time in the edit screens.
But in JIRA; date/time of a History entry matches that of when it was created. However, the date/time of a Work Log entry matches that of when the work was conducted.
Yes. I'm not sure how that's relevant though. Look at how the issues have been changed and work logged against them.
Hi Nazeer,
Not sure I completely understand your question, but you might want to look into burn up charts instead of relying on burn down charts.
Below is one of the scenarios for the issue in burndown chart;
What we missed in our initial planning was creating of testing subtasks in parent issue but one can argue subtasking anyways hasn’t happened for stories.
Ideally a task should not have estimated effort >1d which helps in measuring progress. Is it so?
Additionally total effort for a parent story should also consider effort for testing the feature which again need to be estimated during planning meeting based on the scope, complexity of feature.
Please let me know your suggestions.
It looks like you're new here. Sign in or register to get started.
