Work is Done or Not-Done
Scrum does not require the use of user stories, story points, or burn-down charts. They are commonly used as a best practice, but it's important to understand that they aren't framework requirements.
With that said, widely-accepted agile frameworks generally treat work as either done or not-done. Product and Sprint Backlog Items are never "partially done," so they aren't burned down until they have meet the Definition of Done.
Right-Size Your Granularity
If you want deeper visibility into done/not-done, you'll probably need to refactor your Sprint Backlog and burn-down chart to track tasks rather than user stories. If you do that, then you can burn down each task as it's 100% done, giving you a more nuanced trend line.
However, note that "more nuanced" doesn't mean better or more accurate. The additional overhead of decomposing and tracking work to significantly more-granular levels (ideally while keeping INVEST criteria in mind) often exceeds the benefit of doing so. Excessive granularity rarely leads to improved delivery of the user stories or Sprint Goals. In other words, it generally creates the illusion of greater precision without actually making the estimation or delivery processes any more effective.
Furthermore, excessive task-tracking often defeats the self-organizing principles of agile frameworks, leading to more up-front planning and less emergent design. If you over-constrain the solution space through prescriptive upfront design and planning, you take away the collaboration and just-in-time/just-enough flexibility that makes empirical control frameworks like Scrum agile in the first place.
Trend Lines: A Function of Backlog Item Size
Having a trend line that doesn't budge until the very end of a Sprint may be a framework implementation smell, but bumpy or stair-stepping trend lines are usually just a symptom of tracking larger chunks of work. What you want is a predictable cadence, not necessarily a smooth graph. Provided you have a downward trend every couple of days and are meeting your Sprint Goal more often than not, I wouldn't worry about it. It's only a problem if it creates a problem!
On the other hand, if the Scrum Team really needs the additional visibility, then the whole team needs to accept the additional overhead of planning and tracking at a more granular level. Only the Scrum Team can determine whether that's a useful trade-off or not.