Aren't the jumps in the burndown chart very clear indicators, when Tasks were misestimated?

The suggested solution ignores, that Tasks can by created later in the Sprint. Tasks can also be deleted.

A perhaps better solution would be, to remember the initial estimation as a sum of all task estimation in the Story.

We could also show the sum of all jumps in the burndown chart.

My goal is to know exactly where was the problem to focus on that place. There could be situation where 80% of story tasks have good estimation and 20% wrong estimation.

I want to know which tasks.

Sum of all story tasks initial estimations and sum of all jumps would be very nice - this would let me know scale of estimation problem. But I still will not know where.

I can get exact tasks reestimation information on daily meeting but it would be nice to have tool support. On Sprint retrospective would be easier to initiate proper fix actions and work suggestions.

As a workaround in current implementation we write initial task estimation in first comment and we create task comment when initial estimation change would occur. This information will stay in tool, and in sprint retrospective we can talk about this.

I would suggest to add both sums and one additional field for initial task estimation - it would give us all needed information.

How do you think?

I do not necessarily agree. The problems with this suggestions are twofold:

Firstly, Scrum Teams should eventually manage to get quite good results estimating Tasks, so most of the time the additional UI space for the initial estimation would be wasted. If you actually have issues with Task estimation, Daily Scrums and Sprint Retrospectives are exactly the place to discuss it. There is no substitute for communication in Scrum, so talking about it is the best solution. If estimation is an issue, it should come up in Standup and Retrospective meetings, anyway.

Secondly (and this is partly related), including additional measures is always a trade-off to usability. Displaying more stuff in the UI might be well-intentioned, but in the end of the day, it distracts users from what is really important. In my optinion, Kunagi displays more than enough information already, so I'm generally cautious about including more.

There is a very old idea in iss16 that might cover things like that. Scrum has quite some pitfalls that can, presumably, be auto-detected and displayed. But admittedly, I do not feel that we are ready to tackle exciters like iss16, yet. There are more urgent tasks at hand to ensure stability and usability. But I am pretty confident that it's something we will do in the future.