Percentage complete - timeline

In Scrum who says that those dates are valid?  According to the Scrum Guide section where the Sprint is described

Each Sprint may be considered a project with no more than a one-month horizon

Start and end dates of a project would be the same as a Sprint.  Percentage complete would be 0% at the beginning of the Sprint and 100% at the end because the intention of a Sprint is to deliver a potentially releasable increment of work every time. Dates do not slip because the timeboxes of Sprint Length is not changed. 

If an organization shifts to using Scrum, the entire organization has to shift not just the part of the organization that does work. The executive team needs to learn how their behavior, interactions and expectations must shift in an agile organization. That is part of the Scrum Master's job. 

Thanks. We still are project based and need to plan accordingly as we have many systems throughout the organization and need to prioritize. It’s not funding by product at this time. 

In our organization we recently have shifting to using scrum and have always been  required to track start and end dates to a project, percentage complete , indicate a reason if the date slips  and show this to our exec team each quarter.

Now that Scrum is being used, and value is being demonstrated empirically each Sprint, does anyone still require the things you mention? If so, why?

Yes they still require it as it takes several sprints to complete the intuitive and they are still very focused on dates . 

Yes they still require it as it takes several sprints to complete the intuitive and they are still very focused on dates. 

Is there any inspection for the increments delivered each sprint to any environment where valuable feedback can be adapted for the next iterations ? If yes, then do these end dates still remains valid ?

Leesa,

Reading your posts, I am just confused as to the reasons why your organization wants to change to Scrum.

It seems that your organization still has a preference for working under fixed-scope projects.   Unfortunately, that approach actually doesn't support an Agile/Scrum way of working.

Does your company have a way of incorporating feedback from past sprints that may alter the scope and/or direction of such projects?   If not, you may be getting some value out of "chunking up" your work into increments/sprints, but you are still working off of a list of to-do's, which is not working Agile-ly (flexible, nimble, adaptable).

You can ask your scrum team and based on expertise/bandwidth anyone from your team can do it. 

Beauty of scrum is it's non prescriptive and team can fit their own process/practices to align with their context.

This is very common ask in majority of organizations (specially enterprise level) and in most of the cases they directly encourage SMs to take this responsibility.

What if you deliver all your scope by the fixed deadlines, but customers found little or no value? How important are the dates now?