Let's say a project has 2 or more Sprints and for each sprint you are using a burn down chart to track the Sprint progress. If at the end of the first Sprint there are tasks that have been started but are not completed and hence will go into the next sprint to be worked on how would those tasks be handled in the next sprint burn down chart - do you adjust the estimated time for the tasks to reflect the fact that some work has been done on them or use the original estimated time? Thanks.
I've tried both with my Team. The one we found to make more sense is to adjust the estimate. The whole idea of Agile is to update your plan based on new information. Updating your estimates to reflect the work remaining for your Stories will make estimation much easier, and will better reflect what is actually happening in Sprint 2.
The only thing you've really 'lost' is the overall effort that was required for that Story, but it was decided (in our case) that we didn't really even need that.
TL:DR: Use the original estimate. It keeps your data consistent, holds the team accountable and reflects the actual nature of work in a Scrum setting.
This answer is based on making a living as a full-time agile coach and having experienced both the healthy and unhealthy ways to deal with unfinished work.
Why: One of the great things about agile is its binary nature for tracking work. Work is either Done or Not Done. There is no ambiguity to this. At the end of the sprint, the story is "potentially shippable" or it is effectively "not even started". There is never a grey area of "Oh we're 90% done" and then be 90% done for three sprints.
Caveat: I'm going to talk about Shu level Scrum, or "starting scrum". As a team gets too high performing (or Ri level) they can start experimenting with the basics. Until they do, I always recommend you start with the basics. The reason is there is 30+ years behind why those basics work. If you've got issue with this premise, I recommend Ron Jefferies "We Tried Baseball, it Didn't Work" Blog.
First off, when you reach the end of the sprint, everything is moved from the sprint backlog to the product backlog. Planning starts all over. It's been two weeks and the Product Owner needs to prioritize the backlog based on the current reality. Even though the team just spent two weeks on something, it may no longer be a priority and the product owner may decide to drop it. This is 100% okay, it's not sunk cost. Instead, it's realizing something isn't valuable anymore and deciding not to ship it and thus incur the cost of supporting it. A company I worked for once ended up over a barrel with eBay because they'd deployed this "cute" feature, that didn't really work which eBay then ended up relying on for mission critical business. They ended up having to support this poor feature for over a decade.
Next up, you don't re-estimate work in progress. There are a number of reasons. The top of the list is the rest of the world didn't just sit still for the last two weeks. Even if the story is "90% done" (see above), it hasn't been deployed and I know of very few systems that don't change over the course of two weeks. That code is likely out of date to the current system. You need to go back through the whole story and make sure it works with today's environment.
Re-estimating will also completely shred you velocity metrics. This will lower the team's ability to predictably plan the work.
End of the day, if you are not finishing stories in a sprint, you need to be asking why not putting a bandaid on the problem and moving forward. Make your stories smaller, plan less work, fix your release process, whatever is. Just don't re-estimate.
Oh and don't split the story into done and not done work. That's a whole other agile anti-pattern.
A Sprint burn-down chart tracks work remaining, not work completed. If you want to track work completed, use a burn-up chart instead.
Inspect-and-Adapt Incomplete Work
The fourth value of the Agile Manifesto is responding to change over following a plan. Carrying work forward automatically not only violates the time-boxing principle that underpins the Scrum framework, but it also reduces a team's ability to adapt to evolving requirements.
When implemented properly, work in Scrum is never carried forward automatically from Sprint to Sprint. Increments of work, whether done or not-done, must always be inspected and adapted at time-box boundaries. Any work that is incomplete at the end of a Sprint is placed back onto the Product Backlog, where the Product Owner can reprioritize it (or even discard it altogether) based on changing business needs or the current Sprint Goal.
The next time the work is in scope for Sprint Planning, the team replans and re-estimates the work based on new information, current context, and level of effort remaining to complete the work. While lessons learned about the work from previous Sprints can inform the estimation process, historical estimates are discarded as irrelevant to the current time-box.
The following answers are related, although the questions they address are not necessarily exact duplicates of the one you're currently asking. They offer additional explanation and guidance about the importance of re-estimation and replanning.