This is a surprisingly common trap to fall into. I worked at a startup in which the CTO criticized my dev team for not having a perfectly linear burn down chart. Every week in our retro we had the same discussion about how to improve the shape of our burn down chart; we tried putting higher valued stories at the front of the queue, involving QA earlier in the sprint, and cranking out 1 pointers mid week to tweak the graph. We rarely achieved the perfect shape. On top of this we also had one week sprints, which made it difficult to plan for the future or work on spikes, so we ended up doing very little high-level, architectural planning.
I remember one week my team cranked through their allotted stories so fast that we ran out of work two or three days into the sprint. We decided to take on a couple extra easy stories that we knew we could finish before the end of the week. Rather than being praised for doing extra work, we were criticized for "introducing volatility into the sprint". In other words, we messed up the shape of the burn down chart.
I'm currently working at a place that has virtually no process, which has it's own challenges, but I'm happy that I'm not arguing about burn down charts anymore :)
I remember one week my team cranked through their allotted stories so fast that we ran out of work two or three days into the sprint. We decided to take on a couple extra easy stories that we knew we could finish before the end of the week. Rather than being praised for doing extra work, we were criticized for "introducing volatility into the sprint". In other words, we messed up the shape of the burn down chart.
I'm currently working at a place that has virtually no process, which has it's own challenges, but I'm happy that I'm not arguing about burn down charts anymore :)