Need urgent advise pls -Level of tracking and monitoring required in a fixed bid agile project

Cost and duration can indeed be fixed in agile practice. Quality is also guaranteed. The flex lies in scope.

There are of course no Scrum "ceremonies" but there are events, the most important being the Sprint. The Sprint is what has a start and end date. Moreover, the whole point of a Sprint is to produce a Done increment of immediate usable quality which meets a Sprint Goal. Those are the commitments which Developers are expected to make, so empirical outcomes can be obtained each Sprint timebox.

Scrum is about learning to build the right thing at the right time. The items planned into a Sprint, such as user stories and tasks, are a forecast of the work the Developers believe they need to do to meet their commitments, and are therefore subject to change. I'd suggest that this is where a different understanding begins. Without that, you may indeed have the "ceremonies" you speak of and a ritualized simulacrum of Scrum, but any expected agile outcomes will prove elusive.

If you are working with a new team that did not work together on a similar technology/product domain any attempt at estimation has very high uncertainty. 

Even if you estimate in the SP, you need a couple of Sprints to figure out the team Velocity.

In such cases, there is a temptation to use Time estimates everywhere, however, without the past history the time estimate is also very unreliable.

You need to make sure that your stakeholders understand this.

Still, you need to somehow plan the initial Sprints. 

In such cases, the initial Sprints need to be planned with much higher scrutiny. Breaking down the User Stories and planning in detail, who does what, and when might be necessary to get the confidence for the given Sprint.

Once you are more sure about the team velocity, you should be able to measure more reliably how many Sprint is going to take to move the rest of the Product Backlog to DONE. 

Again, make sure everyone understands that.

Besides the estimations, it is very important to have the Product Backlog properly ordered around the value. If you have a fixed cost/time, it looks like the only moving part is scope.

Make sure you deliver the most valuable things as soon as possible. 

You need to be smart about what value means for your stakeholders/customers and don't jeopardize value delivery by chasing perfection (e.g. perfectly looking UI, or functionalities that are very nice but not necessarily important) or building too much of the foundation without the value being delivered. 

Thanks a lot for your response Ian.

Unfortunately we have fixed scope too. My bad on ceremonies - its events as you had mentioned. As a scrum master, what do you suggest should be done. For a 5 month project, do you think sprint level outcomes are good enough to predict if entire scope can be completed? One big risk that i see is my PO is regularly interacting with the client to create the product backlog and as of now we dont have visibility on the complete size.

Hi Jacek, Thanks a lot for your response. Unfortunately, the product backlog is being created, we only have initial UI/UX provided by client. PO is in discussion with the client and creating the backlog while we have already started the sprints. What do you suggest, when does the backlog be created in such projects? Sprint 0 is not good enough for such a big project. Should we charge client for creating backlog in the initial few months since its a fixed scope/time/cost project? else in other agile project scope is generally evolving over a period of time.

Another fact - There is a UAT after 5 months, so no product deployment till 6 months.

The Product Backlog is emergent. Thus whatever you have so far is your initial Product Backlog. However, it looks like it is very vague and it needs a lot of refinement. 

Starting the Sprints is fine even if the Product Backlog requires a lot of refinement. The consequence is that the team will need to spend more time during the Sprint on the refinement. However, still, valuable Increment should be delivered from Sprint 1. 

the product backlog is being created, we only have initial UI/UX provided by client. PO is in discussion with the client and creating the backlog

The above suggests that the scope is not fixed.  Maybe just the Product Goal is fixed and some elementary frames/features are fixed, but there might be still room for how the Product Goal will be realized and how in detail those features will finally be realized.

I would argue that if the Product Owner is still talking to the stakeholders to gain insights into what is needed, then your scope is not fixed.  If the scope was fixed, you would have all of the requirements before you start. 

The word "estimate" does not appear anywhere in the current revision of the Scrum Guide.  However, when discussing Product Backlog Items there is a reference to size. 

Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work

So there is no reason that you couldn't use hours instead of Story Points.  However, the will still be estimates (i.e. guesses) made at a specific point in time based upon known information.  So, don't expect them to be perfect. 

I am going to be honest with you.  Based upon what you say you are doing, you sound much more like a Project Manager than a Scrum Master.  I get the impression that you are not using the Scrum framework. It sounds more like you are doing a waterfall project and using some Scrum terminology.  It might be worth taking a good look at that and start calling it what it is.  Using Scrum terminology can actually cause more confusion than benefit.

Hi Jacek, Thanks for your response.  Yes, we are spending quite a bit of time during the sprint to refine more items and creating a backlog. 

The reason I say we have fixed scope is that we have a set of define features which needs to be delivered which are augmented by 300+ UI/UX files so client expects we deliver all the functionality as given in designs. PO is just working with the client to create user stories based on the mockups provided. 

Hi Daniel, thanks for your response. You are absolutely right that this is not a agile project in true sense. The part of scrum that we use are just the events and we try to prioritise the most valuable part of the backlog. Otherwise, i feel this project was more suited for waterfall and could have been delivered successfully, however, as i mentioned i joined the project late. The role is that of a PM only and by far not that of a SM. Prior to this i worked as SM in SAFe env. and it was a agile project in true sense and spirit. 

So coming back to my problem - I have 2 - 

1. In another couple of sprints i would know what will be our avg. velocity which the team can sustain, however, absence of a high level backlog (not estimated) wont give any confidence whether this sustainable velocity would suffice the project deliverables. So i am asking my PO to create atleast stories (at high level may be) and put them in backlog with priority order which can help us to predict backlog size. Refined backlog will take lot of time as its being done sprint on sprint basis. Pls suggest if there is a better way to do it? or could have been done in a better way?

2. What is the level of tracking a PM needs to ensure that project can be delivered within the given time frame? So my original question in this thread - if we are tracking based on target end date, daily status calls and tasks status, will capturing task level estimates help (fyi  - single story will have multiple tasks) that too in hours (which can be wrong in many ways). But since the QA team needs to plan their activities we need to ensure that dev. team delivers the stories on committed dates. May this question is not relevant to this forum, but if you can answer, it will be helpful.

In another couple of sprints i would know what will be our avg. velocity

What are you using to determine the velocity?  If it is story points it could backfire on you. Because the more the developers know about the work and become familiar with it, the estimates could change which will not help you at all. In fact, you should assume that the estimates will change over time. 

If you look at the throughput or cycle time for the items in your backlog, you will have a much better chance of getting realistic numbers that could help. 

Your method for #1 seems realistic. You will have to be able to know something about what is coming in order to understand the total work.

As for your #2 question, I can't answer that.  Only the PM can. (And I hope by PM you are referring to a Project Manager.)  Since your processes are unique to your organization, you will need to arrive at your own methods for tracking and forecasting.  There are a lot of places on the web where you can get project management techniques and advice. I would look for those and forget about Scrum answers for this project. 

If your schedule is fixed at 5 months, you have a stable team and have derived the fixed cost from there, and have a fixed scope of work, then why are you bothering using Scrum, or any agile methods? The overhead of some of the events could be too much for the team. Although regularly revisiting your plan, reviewing progress, and having retrospectives to improve your process are good, fitting them into fixed-length timeboxes may not be the most effective use of your time.

Hi Shalabh, you are not alone here, we have 9 Scrum teams and in one of the projects, there is are similar challenges where management signed a contract with a fixed scope and we are delivering in Agile. I also joined the organisation in the executing phase and things happening are driving me nuts with this Wagile or Hybrid delivery during discussion in our Scrum Masters catch up meeting. I feel your pain.

We have Big Room Planning sessions every quarter where we identify critical paths, team dependencies,  leading to having a product backlog for each quarter. Drop/Release dates are provided to the client based on story estimates and these drop dates have not been met because of Cone of Uncertainty as the dev keeps discovering complex task thus the backlog needs to be adapted to suit.

We have same issues with our average velocity and the devs are on pressure to deliver as estimates have been used to provide drop dates for the client. We have just decided after the last Retro to work in line with what can be completed in a Sprint while drop dates provided will be adapted according. Our client appears to be a little flexible as per the PM, however outcome will be determined soon. 

I will be holding a Leadership Retro next week to understand the expectation of the Chapter Leads in view of the attendant issues.