Project tracking ownership lies with whom?

A Development Team should not simply be moving work from one Sprint to the next because it didn't get done. A Development Team should be able to forecast the amount of work that they can do in the Sprint reasonably well, although several factors may affect their ability to do so. A Development Team should also be able to commit to completing the work that is necessary to achieve the Sprint Goal (which, in my opinion, should be less than than total forecast work for the Sprint). How the team forecasts their work and commits to the Sprint Goal should be based on factors including the knowledge that the team has with respect to the domain and the product and the tolerance for risk of the development organization.

It is difficult to say when the project will be completed because the exact work that is needed is being discovered throughout the effort. However, if you make the assumption that the known body of work is all of the work and using measurements such as cycle time, throughput, and velocity, you can estimate when the backlog, in its current state, is likely to be completed. Of course, you do need to consider the probability of achieving this, knowing that you are estimating or forecasting with this data and work that is further out is probably less defined and less likely to be in the correct order or even has uncertainty as if its needed.

There is no commitment to deliver on certain date from development team.

Shouldn’t they commit to delivering at least one Done increment by the end of each Sprint?

Only rough estimation is done and if it is not completed in a sprint, the user stories can be moved to next sprint.

If that was the case, how would a Sprint Goal be framed and met and what purpose would a Sprint serve?

The delivery ownership of end solution lies with development team and not scrum master. 

Going to start with disagreeing to that statement.  The delivery ownership of an end solution lies with the entire Scrum Team.  Each role in the Scrum Team has responsibilities that lead to ownership of all the work done by the entire team. 

We can't surely say when the project will be completed?

I can argue that in the "traditional method" teams very rarely were able to provide an accurate estimate of when a project would be complete. At least in my experiences deadlines were often missed, usually extended, due unanticipated reasons. In agile terms a project is completed when the stakeholders say that you have satisifed their problem and needs.  That could be quick or long in occuring but it is all determined by the feedback provided continuously during the process. 

Every one does their job and update the tasks. If it succeeds, all will get the credit. If it fails, every one sees others faces.

I am not sure I follow this statement.  But there is much more than "Every one does their job and update the tasks". In fact tasks are not even needed so that statement really confuses me.  In my opinion everyone gets equal recognition for everything that occurs. And faliures only occur when you do not inspect and learn from the unexpected happenings. If you do that then you will not fail and will ultimately deliver the value that is needed.  Since there is no defined end date, failure would only occur if you quit trying.

Thanks Thomas owens, Ian Mitchell and Daniel Wilhite for the replies. 

Hi Prakash. I'm a little curious about the effectiveness of the Product Owner.

The delivery ownership of end solution lies with development team and not scrum master. 

The ownership falls onto the entire Scrum Team. Different folks do different things at different times, but they all work together. This is what helps align everyone to a purpose.

The whole team consumes the duties of a traditional PM in various ways. What they work on in a given Sprint reflects the PO being a good representation of customer needs. The PO collaborates with the Dev Team in Sprint Planning to align on the creation of a functional Sprint Goal, prioritized by the customer needs aka value.

That Sprint will include all work needed to realize that Sprint Goal, but that's not to assume a Sprint will only contain Sprint Goal work. There are a couple ways of looking at this.

1. Perhaps it may contain work that is expected to not be finished but it's the next-in-line most important work.
   • Better to make progress on that then complete smaller stories that aren't as valuable.
     • That work should probably not be started/completed before the Sprint Goal work, but it's ok to expect that work to be started and not be completed.
       
        
2. Perhaps you only start the Sprint with just Sprint Goal work in it but only utilizing 80-90% of teams capacity.
   • Once the Sprint Goal is complete, pull in the next most important work.
   • Team may also encounter new work that is needed in order to call the current Sprint Goal complete, by way of learning something from completing some of the stories in the Sprint. They are expected to be able to pull in that work too, and that's ok.

There are several other ways of planning a Sprint and In-Sprint behavior, but the point I'm attempting to make is the mindset of incomplete work items vs incomplete Sprint Goals. The Product Owner is a full member of the team and its purpose is to assist the Dev Team in building the right thing. A PO should be able to determine if the scope of a story or it's useability is good or not anytime during the Sprint if needed.