In the interests of trying to provide a good answer to the question, I've rewritten my original answer to both better explain it and to address a number of the points in the comments:
Firstly, a quick overview of agile ideas and methodologies, to set the stage for the answer. There are two important rules to agile development that everyone should know and remind themselves of regularly. Combined they can save a lot of misunderstanding and misinformation:
- Agile is an adjective; not a noun. If someone says "We do agile", or "Agile is ..." then they have misunderstood the whole idea of agile development. Agile isn't a thing, any more than rapid in Rapid Application Development (RAD) is a thing. A good rule of thumb for determining if you are using the word correctly is to swap it for "nimble". "We do nimble" sounds silly; so this tells us "We do agile" is a bad use of the word. "Nimble is a mindset" sounds silly; this tells us the "Agile is a mindset" is also a bad use of the word. "We have adopted a set of nimble processes" and "we are a nimble development team" both make sense, which tells us these are good ways of using the word agile.
- One of the key principles of agile development is "Individuals and interactions over processes and tools". In other words, put what works for you at a given time before all dogma, "best practice" (a poisoned chalice of a phrase, if there ever was one) or any real or imagined rule of how to take an agile approach to development. If you come across someone saying "story points are only for stories, thus the name" or "Story points and ideal hours are not interchangeable" then they have forgotten this core principle and are putting process before people. If you want to measure stories in hours, tasks in elephants etc, then do so. If anyone tells you you are doing it wrong, point them to the agile manifesto and politely ask them they are advising you badly. There's an excellent article on real & ideal hours and story points at http://vladhorby.wordpress.com/2007/09/04/agile-adventures-ideal-vs-real-time/, which is well worth a read.
So back to my original answer, which I have rewritten to clarify what I was trying to advise; it was clearly badly phrased initially as it confused a number of people.
The scenario described is of a situation where a team has estimated a set of stories and these are being assigned to each sprint in turn. However, due to the duration of each story been similar to the length of the sprint, the scrum master's job of tracking progress is made difficult. Scrum guidelines suggest that a activity only be marked down on the burndown once it is done. Thus, the progress line flat-lines until the end of the sprint, before plummeting as the stories finish.
The simple reason why this happens is because the activities aren't granular enough. A solution to this is to take each story and decompose it into tasks during the sprint planning meeting. that way, each task reaches done more quickly and so can be marked down on the burndown chart. Thus progress is more accurately recorded.
Whilst it might be tempting to estimate the tasks in hours (or days) during the sprint planning meeting, there is an alternative approach that can provide valuable information to the scrum master on the the velocity that the team is achieving. That alternative approach is to estimate the tasks in story points (or "bolitas" - see the link above) too. These remain arbitrary amounts. Though some teams choose to equate a story point with an idealised "man day", this isn't universal or even necessary for some teams. As always with agile development, do what works best for your team. If you estimate tasks in story points, and record the hours spent, you can obtain hours spent vs estimated story points metrics. This can form a good way of determining the team’s velocity and estimating accuracy. These figures can then help inform discussions around improving estimating in the retrospective and in giving more reliable real duration estimates of story points in the future.
Addendum
I have been asked by "Venture2099" to expand upon what "Individuals and interactions over processes and tools" actually means in practice. What this means in the real world was superbly expressed up by a talk at QCon London in 2013 by Glen Ford. The slides are available at http://qconlondon.com/london-2013/qconlondon.com/dl/qcon-london-2013/slides/GlenFord_PeopleOverProcessApplyingItInRealWorldSoftwareDevelopment.pdf, but without the video, they likely lack enough words to fully get the message across. However, the following quote superbly sums it up:
"Process is not the rule of law. Rather it is a set of concepts in which to frame the interaction between individuals in order to facilitate the efficient generation of value. The advantage of quality interactions is you decrease the reliance on process. Encourage quality interactions".
In a manufacturing environment for example, one needs strict processes. However, in a creative exploration of the unknown, which typifies software development, they are largely a hindrance. Unless those processes are agile themselves. The most agile of process is one that grows out of good inter-relationships between a team of people that want to do the best job they can and are empowered to do so.
All agile methodologies should embrace the "people before processes" ideal by offering guidelines, rather than rules. Rules beget inflexible processes and a belief in some that there is "one true way" of "doing agile". That's why it's always important to remember the "people before processes" idea when insisting that an agile method must be implemented in a certain way or before talking of agile "best practice" and the like. Such behaviour undermines a fundamental principle of agile development.
